Closed SimoneTiberi closed 1 year ago
Hi @SimoneTiberi
Thanks for submitting your package. We are taking a quick look at it and you will hear back from us soon.
The DESCRIPTION file for this package is:
Package: IsoBayes
Type: Package
Title: IsoBayes: Single Isoform protein inference Method via Bayesian Analyses
Version: 0.99.0
Description: IsoBayes is a Bayesian method to perform inference on single protein isoforms.
Our approach infers the presence/absence of protein isoforms, and also estimates their abundance;
additionally, it provides a measure of the uncertainty of these estimates, via:
i) the posterior probability that a protein isoform is present in the sample;
ii) a posterior credible interval of its abundance.
IsoBayes inputs liquid cromatography mass spectrometry (MS) data,
and can work with both PSM counts, and intensities.
When available, trascript isoform abundances (i.e., TPMs) are also incorporated:
TPMs are used to formulate an informative prior for the respective protein isoform relative abundance.
We further identify isoforms where the relative abundance of proteins and transcripts significantly differ.
We use a two-layer latent variable approach to model two sources of uncertainty typical of MS data:
i) peptides may be erroneously detected (even when absent);
ii) many peptides are compatible with multiple protein isoforms.
In the first layer, we sample the presence/absence of each peptide based on its estimated probability
of being mistakenly detected, also known as PEP (i.e., posterior error probability).
In the second layer, for peptides that were estimated as being present,
we allocate their abundance across the protein isoforms they map to.
These two steps allow us to recover the presence and abundance of each protein isoform.
Authors@R: c(person(given = "Jordy",
family = "Bollon",
role = c("aut", "cre"),
email = "jordy.bollon@iit.it"),
person(given = "Simone",
family = "Tiberi",
role = c("aut", "cre"),
email = "simone.tiberi@unibo.ch",
comment = c(ORCID = "0000-0002-3054-9964")))
biocViews: StatisticalMethod, Bayesian, Proteomics, MassSpectrometry, AlternativeSplicing,
Sequencing, RNASeq, GeneExpression, Genetics, Visualization, Software
License: GPL-3
Depends: R (>= 4.3.0)
Imports: methods, Rcpp, Biostrings, data.table, glue, xml2, DescTools, stats, doParallel, parallel, doRNG, foreach, iterators, ggplot2, HDInterval
LinkingTo: Rcpp, RcppArmadillo
Suggests: knitr, rmarkdown, testthat, BiocStyle
SystemRequirements: C++11
VignetteBuilder: knitr
RoxygenNote: 7.2.3
ByteCompile: true
URL: https://github.com/SimoneTiberi/IsoBayes
BugReports: https://github.com/SimoneTiberi/IsoBayes/issues
Hi Bioc reviewers,
we submitted IsoBayes
, a Bayesian inference method to perform inference on single-isoform proteins from proteomics data.
Looking forward to your feedback.
Kind regards, Simone and Jordy
A reviewer has been assigned to your package. Learn what to expect during the review process.
IMPORTANT: Please read this documentation for setting up remotes to push to git.bioconductor.org. It is required to push a version bump to git.bioconductor.org to trigger a new build.
Bioconductor utilized your github ssh-keys for git.bioconductor.org access. To manage keys and future access you may want to active your Bioconductor Git Credentials Account
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
On one or more platforms, the build results were: "ERROR". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.2.tar.gz macOS 12.6.5 Monterey: IsoBayes_0.99.2.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Hi Laurent, I see there are a few errors which (I think!) we didn't have locally. I'll fix them and push an update.
Thanks, Simone
Received a valid push on git.bioconductor.org; starting a build for commit id: 588eff69573ec6915c120215d2096be755cc5020
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
On one or more platforms, the build results were: "ERROR". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: macOS 12.6.5 Monterey: IsoBayes_0.99.3.tar.gz Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.3.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Received a valid push on git.bioconductor.org; starting a build for commit id: a65913093266e0ae6866cb42ca1f37503fce370e
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
Congratulations! The package built without errors or warnings on all platforms.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: macOS 12.6.5 Monterey: IsoBayes_0.99.4.tar.gz Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.4.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Received a valid push on git.bioconductor.org; starting a build for commit id: bc9383d2ea0f6998b2a21cb4d94a0a35b1edcfca
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
Congratulations! The package built without errors or warnings on all platforms.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.5.tar.gz macOS 12.6.5 Monterey: IsoBayes_0.99.5.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Hi again Laurent @lgatto, ok, we sorted the previous issues.
Although @bioc-issue-bot did not remove "ERROR" label, there are no errors in the current checks, so I think the package should be ok now.
I'll leave it to you, and wait for your feedback. Simone
Hi @lgatto, and @vjcitn, this issue has been quite for the last couple of weeks (I suppose for summer vacations). Nonetheless, just in case it was forgotten, I'd like to gently put this submission to your attention.
Thanks, Simone
Oh hey, what’s my role here?--tOn Aug 18, 2023, at 6:06 AM, Simone Tiberi @.***> wrote: Hi @lgatto, @vjcitn and @ttriche, this issue has been quite for the last couple of weeks (I suppose for summer vacations). Nonetheless, just in case it was forgotten, I'd like to gently put this submission to your attention. Thanks, Simone
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
Hi Tim @ttriche, sorry I tagged you by mistake!
@lgatto was away on holiday and should be returning this week. He will look at your package and have feedback soon. We apologize for the delay.
Thanks for the clarification. No problem, I just wanted to make sure someone was on it.
Simone
Hi Laurent @lgatto and @lshep, any updates on the review process?
Thanks, Simone
Hi @SimoneTiberi - I will post more technical comments tomorrow or on Monday, but I wanted to write this part already so you could give it some thought. It concerns an important concept for the Bioconductor project, namely the re-use of classes and functionality.
Bioconductor is well known for it's core classes, that allow for better interoperability between independently developed packages. The SummarizedExperiment
is a prime example thereof, that is both used for RNA-Seq and quantitative proteomics data. In addition, there's the QFeatures
class that focuses on the multi-level structure of proteomics data (precursors, peptides, proteins), that you tackle in your package. My request for you would be to make use of this carefully crafted and maintained infrastructure in your package, at least use SummarizedExperiments
as inputs. We can also discuss the usage of QFeatures
, if you want.
In you vignette, you say that IsoBayes works with outputs from MetaMorpheus or Percolator, but why not make it applicable to any software by using SummarizedExperiments
or QFeatures
, and the QFeatures::readSummarizedExperiments()
or QFeatures::readQFeatures()
functions? Currently, you have very a specific and limited (in scope) load_data()
function.
In addition to making use of existing classes and enable interoperability with other packages, you would also benefit from other functionality, such features aggregation and visualisation, to cite only two.
\code{load_data}
syntax
several times, and the function name doesn't show up in the html
vignette.[ ] In input_check_plot.R
(line 2, column 33) you use class(x) != "list"
to check the class of variable x
. It is recommended to use
is(x, 'class')
or inherits(x, 'cass')
in such cases. Similarly,
you can use is.character()
in input_check.R
.
[ ] Avoid using '=' for assignment and use '<-' instead.
[ ] The Bioconductor (and many other) style guide recommends
function length is 50 lines or less. You have 5 functions greater
than 50 lines: load_data()
, get_peptides_from_idXML()
,
inference()
, plot_relative_abundances()
and
input_check()
. Shorter functions are easier to read and
understand, less error prone, easier to maintain and easier to test.
[ ] Another suggestion of the many style guides is to keep shorter lines, typically < 80 character, as they are easier to read and understand, and thus less error prone. In you code 255 lines (14%) are > 80 characters long. If possible, try to split/simplify them.
[ ] Consider multiples of 4 spaces for line indents to facilitate reading of your code. In your 607 lines (34%) are not. This can be handled automatically by your editor, or you can use the styler package to automate this with
styler::style_pkg(transformers = styler::tidyverse_style(indent_by = 4))
[ ] Re-use of classes and functionality - see above for better
integration with the Bioconductor project. You PSM_data_loaded
input data is a rather convoluted list of dataframes and logical
vectors. Your section '5.3 Input user-provided data' essentially
argues for the recommendation to used default Bioconductor
infrastructure to handle data in a standardised way.
[ ] Parallelisation uses BiocParallel
: I see that you use
doParallel
for parallel processing. We prefer for you to make use
of BiocParallel
, that supports a selection of parallelisation
backends, and thus greater flexibility for the users. Is there any
specific reasons you didn't use it?
I see that you have and extra Rmd file in inst/scripts. Could this one not be useful for users and thus be used as a proper vignette for the package?
Received a valid push on git.bioconductor.org; starting a build for commit id: a4172450d734cb8aa5953fa585afb5d48e2b0776
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
On one or more platforms, the build results were: "ERROR". This may mean there is a problem with the package that you need to fix. Or it may mean that there is a problem with the build system itself.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.10.tar.gz macOS 12.6.5 Monterey: IsoBayes_0.99.10.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Received a valid push on git.bioconductor.org; starting a build for commit id: 5cebbb3e74c0551bd3d060bbb9b676679e3b458f
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
Congratulations! The package built without errors or warnings on all platforms.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.11.tar.gz macOS 12.6.5 Monterey: IsoBayes_0.99.11.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Hi Laurent @lgatto , thanks a lot for taking the time to review our work; that was a very through review.
We implemented several of your suggestions, while we argued against others we disagree with.
Here is a point-to-point response.
I hope we addressed all your comments.
Simone and Jordy
load_data
function more general, and it now works the following inputs:
1) MetaMorpheus output;
2) OpenMS/Percolator output;
3) a generic data.frame;
4) a .tsv file;
5) a SummarizedExperiment.Options 3-5 are generic, and can be easily generated by users. I checked QFeatures and saw that a SummarizedExperiment of the psms can easily be extracted as hl[["psms"]]. We also added a note about this in the README and vignettes.
2 blocks are disabled because they only report example code to load the data from alternative inputs (from Percolator and a general tsv file);
Similarly 1 block is redundant (and computationally intensive), because we show 2 ways to run inference
function (1 disabled).
We kept those scripts, even though they are disabled, because we think that it's still useful to show the code of alternative options (for loading the data, and doing inference).
Wrong syntax, fixed now, thanks!
Sorry, we don't fully understand the comment: exactly what piece of information do you suggest adding to the README? Do you suggest adding a link to the Vignette, like "browseVignettes"?
Yes, highest posterior density. We missed it, properly introduced now, thanks.
Unit tests
This is odd; the package only has 3 functions which are exported to users (load, inference and plot). All 3 are tested; why is the coverage 43 % only?
Thanks, we missed this; fixed now.
I know this is a sensitive matter, but I disagree with using "<-". Personally, instead of "<-", I often write "< -" (i.e., smaller than minus). For me, "<-" is more error prone.
I agree, but at the same time I also think that splitting a function too many times is not ideal (for the same reasons: error prone and maintenance). Only 3 functions are exported to the users, and overall we have ~40 functions (36 in R and 3 in C++). Personally, I prefer longer functions than excessive splitting intro micro-scripts.
We split some of the longer lines.
We didn't know this function; thanks!
I agree with re-using classes, but our data_loaded object is only used by IsoBayes package (inference function). Users do not interact directly with this object.
Although in principle we could use BiocParallel, we do have some reasons for using foreach. In particular: 1) we use iterators (so only a part of the full dataset is passed to each thread); 2) we specify the order in which parallel tasks are executed, so that "heavier" tasks are done first -> this avoids waiting for 1 single task to be completed while all other threads are done; 3) we use doRNG to generate independent parallel seeds; 4) doParallel can run on all OS. The advantage of using BiocParallel is that users could define some things, such as the parallel class. But, in order to have the 4 points above, I think that only the DoparParam could be used; this removes the benefit of additional flexibility, and increases the possibility of introducing mistakes, if other classes are used.
Honestly, I don't this it's a very interesting script: we mainly used it to decrease the size of our original dataset, so that the data would fit into the package.
Yes, we generally use mzid files. However, when using Percolator (from the OpenMS toolkit), peptide files are stored in a idXML format. So, only when users use Percolator, we input that format (see our answer above about the possible formats for the input data in load_data).
I was suggestion to add the 'Input data' section, showing how to run the proteomics pipelines to the vignette. It seems quite important for users to have access to that information also within the vignette. Some users might not see that README file before being exposed to the vignette. Feel free to ignore it.
I just wanted to point you to the community guidelines, feel free to
use =
. As far as I know, it's not a good enough reason to reject a
package ;-)
Regarding function lengths: I'll let you decide, but you are provably wrong on this - it's a matter of software maintenability. This is a short and interesting read on the topic.
For BiocParallel
, I don't see any point of arguing. Please
familiarise yourself with the existing infrastructure so that you
can make use of it in the future if necessary.
For unit tests, they are not only meant to test exported functions - your users will also (indirectly) run private functions. See below to test your code coverage:
> library(covr)
> pc <- covr::package_coverage("IsoBayes/")
> pc
IsoBayes Coverage: 42.14%
R/aggregate_components_pep.R: 0.00%
R/aggregate_components.R: 0.00%
R/build_intensity.R: 0.00%
R/check_variables.R: 0.00%
R/get_components.R: 0.00%
R/get_list_pept_prot.R: 0.00%
R/get_peptides_from_idXML.R: 0.00%
R/get_proteins_from_idXML.R: 0.00%
R/list_components_for_MCMC_pep.R: 0.00%
R/list_components_for_MCMC.R: 0.00%
R/parallel_MCMC_pep.R: 0.00%
R/parallel_MCMC.R: 0.00%
R/reorder_groups_by_nProteins.R: 0.00%
R/run_MCMC.R: 0.00%
R/utils_idXML.R: 0.00%
src/MCMC_Unique.cpp: 0.00%
src/MCMC.cpp: 0.00%
R/collapse_pept_w_equal_EC.R: 28.57%
R/load_tpm.R: 35.71%
R/input_check_plot.R: 36.84%
R/input_check_inference.R: 46.15%
R/load.R: 57.00%
R/input_check.R: 61.70%
R/inference.R: 71.21%
R/map_isoform_to_gene.R: 73.33%
R/get_overall_abundance.R: 75.00%
R/run_MCMC_pep.R: 84.21%
R/set_MCMC_args.R: 85.19%
R/plot_relative_abundances.R: 89.47%
R/normalize_by_gene.R: 90.91%
R/aggregate_sim_pep.R: 100.00%
R/build_peptide_df.R: 100.00%
R/convert_EC_to_num.R: 100.00%
R/get_prot_from_EC.R: 100.00%
R/get_res_MCMC.R: 100.00%
R/stat_from_MCMC_PI.R: 100.00%
R/stat_from_MCMC_Y.R: 100.00%
R/stat_from_TPM.R: 100.00%
R/unique_peptides.R: 100.00%
R/unique_protein_abundance.R: 100.00%
src/MCMC_PEP.cpp: 100.00%
And by the way, that's one reason why short functions are useful: they are easier to test in isolation.
Regarding the input data, which is the more important part IMHO, I
am sorry I wasn't clear. You should not overload your load_data()
function and have yet another branch in the long if/else tree, but
standardise your expectations so that your main inference()
function only uses SEs as inputs. That will give you more guarantees
that the input data is (to some extend) valid and will considerably
harmonise your infrastructure following the project's standards.
To make it available to different third party software ouputs, you either document how to convert these to an SE (you already spend considerable space in your vignette on data loading), or you provide individual simpler helper functions to do so. This will allow you to offer smaller input/load functions that do one specific thing, and that will be easier to test and document (see above with regard to function lengths and testing).
In the longer run, the capability to harmonise various third party proteomics software outputs, could be centralised on a package such as QFeatures (readSummarizedExperiment() handles most if not all of my needs for now, but I'm happy to expand based on the needs of the community).
Regarding this:
I checked QFeatures and saw that a SummarizedExperiment of the psms can easily be extracted as hl[["psms"]]. We also added a note about this in the README and vignettes.
The name hl[["psms"]]
is only an example, and a complex data set
could contain several PSM-level assays. I don't see any reference to
this in either the vignette, not the README file - are you sure you
pushed all your changes?
Hi Laurent @lgatto, thanks again for your feedback. I must say that, although I don't agree with all comments, this is the most detailed feedback I have ever received on a package, and it's certainly very useful. So, thanks a lot for taking this review so seriously.
We'll do a few extra edits and update the package.
In the meantime, I'd like to ask for one clarification about the data structure in QFeatures
.
For our analyses, we need peptide level information; in particular, for each peptide:
Now, I did not add a direct reference to QFeatures in the vignettes (sorry, I was unclear: the reference is to SE), because I am not 100% I understand where the "EC" is.
In SE$ProteinDescriptions
below, the protein information seems to be at the gene level.
If we can get that at the isoform-level, then we can easily directly use the data in a QFeatures object directly.
So far, I did not understand how to do that (my bad, I am not familiar with QFeatures).
library("QFeatures")
data(hlpsms)
hl <- readQFeatures(hlpsms, ecol = 1:10, name = "psms")
SE = rowData(hl[["psms"]])
SE$ProteinDescriptions
So, if we manage, we will try to change the load_data
function to also input a QFeatures
object directly, but will not modify the output of load_data
.
It is mainly a list of data.frames with different rows and columns (because some refer to isoforms, while others refer to peptides), so I don't see how we could (easily) fit that into a single SE object.
Also, (sorry for iterating this), this is really just used by inference
function, so users should not interact with this.
Thanks again Laurent, Simone and Jordy
Received a valid push on git.bioconductor.org; starting a build for commit id: 46dd9914a02ccf9ca35e161b320abb43f4a5117f
Dear Package contributor,
This is the automated single package builder at bioconductor.org.
Your package has been built on the Bioconductor Build System.
Congratulations! The package built without errors or warnings on all platforms.
Please see the build report for more details.
The following are build products from R CMD build on the Bioconductor Build System: Linux (Ubuntu 22.04.2 LTS): IsoBayes_0.99.12.tar.gz macOS 12.6.5 Monterey: IsoBayes_0.99.12.tar.gz
Links above active for 21 days.
Remember: if you submitted your package after July 7th, 2020,
when making changes to your repository push to
git@git.bioconductor.org:packages/IsoBayes
to trigger a new build.
A quick tutorial for setting up remotes and pushing to upstream can be found here.
Hi Laurent @lgatto, we have increased the coverage of our tests, and extended the vignette with a final Section about OpenMS/Metamorpheus pipelines (basically copied from the README).
We would be grateful if you could accept our package on Bioc :D
Once we understand, in the readQFeatures
object, where the isoform-level mapping (EC) of peptides is stored, we can easily include that option as a further input to load_data
(although I know that's not exactly what you meant; see my message above -> https://github.com/Bioconductor/Contributions/issues/3084#issuecomment-1755806136).
Thanks, Simone and Jordy
Hi Laurent @lgatto, is there anything else we'd do on the package?
It'd be really nice if we'd have IsoBayes in the upcoming Bioc release.
Thanks, Simone
Dear @SimoneTiberi
A QFeatures object is simply a collection of SummarizedExperiment objects, one for each level such as PSM, peptides, protein, ... or isoform, if you wish so. The example that you point to defines proteins (protein groups, to be precise) from peptides via the protein descriptions. But I don't think or claim you would need QFeatures - an SE would suffice. However, that SE could be an QFeatures element, and build from lower-level features via the QFeatures infrastructure.
Let me emphasise again my point here. You should not overload load_data()
with yet another data structure (QFeatures here). This is not the right approach. You want to focus on one well-defined data structure, one that is widely used/accepted/tested in Bioconductor (SE here), and use that one class as the main input for your work, and leave to conversions such as csv/data.frame to SE to others, or to specialised functions. You have achieved the exact opposite by writing a longer, more convoluted load_data()
.
Now, it doesn't look like you will address this suggestion, which is fine by me - you package is a great contribution anyway. Just let me know if you don't feel that a better/cleaner integration is worth the effort at this stage, and I'm happy to accept now and, if you wish so, help you (or directly contribute) a PR along the lines I'm suggesting.
Hi Laurent @lgatto , ok, got it; we misunderstood some of your comments.
I agree with your suggestion: we will have load_data working with SE objects only.
To facilitate users, we will have 3 functions to generate the SE object from: i) MetaMorpheus output; ii) Percolator output; iii) a general csv.
We will clarify in the vignettes that other ways of generating the SE objects are possible (e.g., via QFeatures
).
If you can help us understand how to obtain isoform-level ECs from QFeatures
, we will provide a direct link/clear explanation.
We will work on these changes in the coming days and update the package in a couple of weeks. In the meantime, yes, it would be nice to have the package accepted so that we can enter the upcoming release.
Thanks again for all your suggestions, Simone and Jordy
@lshep - what do you think of accepting the package (which is a great addition to Bioconductor), while some additional changes are to be expected?
@SimoneTiberi - I don't want to do this without explicit agreement from Lori, who oversees the package reviews.
@SimoneTiberi / @lgatto with the understanding that this is a rare exception to the normal process in case future submissions are made. Normally we expect recommended changes to be made before acceptance as in our experience promises of later implementation rarely come to be. @lgatto if you think it is still in a good usable state as is and hopefully @SimoneTiberi will follow up post acceptance. But yes.that's ok.
I understand, and wouldn't suggest this if the package wouldn't be a useful addition anyway.
@SimoneTiberi - do we both agree to take this on (on a new issue on https://github.com/SimoneTiberi/IsoBayes for instance) beyond the Bioc review?
If it is going to make the 3.18 release it needs to be accepted in the next few hours so it can be listed before the bump and branch tomorrow.
Your package has been accepted. It will be added to the Bioconductor nightly builds.
Thank you for contributing to Bioconductor!
Reviewers for Bioconductor packages are volunteers from the Bioconductor community. If you are interested in becoming a Bioconductor package reviewer, please see Reviewers Expectations.
I've opened this issue to continue with what was discussed here.
Thanks for the review process, and for accepting the package Laurent @lgatto and @lshep.
Good idea about the issue! We'd deal with it within 1-2 weeks.
The default branch of your GitHub repository has been added to Bioconductor's git repository as branch devel.
To use the git.bioconductor.org repository, we need an 'ssh' key to associate with your github user name. If your GitHub account already has ssh public keys (https://github.com/SimoneTiberi.keys is not empty), then no further steps are required. Otherwise, do the following:
See further instructions at
https://bioconductor.org/developers/how-to/git/
for working with this repository. See especially
https://bioconductor.org/developers/how-to/git/new-package-workflow/ https://bioconductor.org/developers/how-to/git/sync-existing-repositories/
to keep your GitHub and Bioconductor repositories in sync.
Your package will be included in the next nigthly 'devel' build (check-out from git at about 6 pm Eastern; build completion around 2pm Eastern the next day) at
https://bioconductor.org/checkResults/
(Builds sometimes fail, so ensure that the date stamps on the main landing page are consistent with the addition of your package). Once the package builds successfully, you package will be available for download in the 'Devel' version of Bioconductor using BiocManager::install("IsoBayes")
. The package 'landing page' will be created at
https://bioconductor.org/packages/IsoBayes
If you have any questions, please contact the bioc-devel mailing list (https://stat.ethz.ch/mailman/listinfo/bioc-devel); this issue will not be monitored further.
Update the following URL to point to the GitHub repository of the package you wish to submit to Bioconductor
Confirm the following by editing each check box to '[x]'
[ x] I understand that by submitting my package to Bioconductor, the package source and all review commentary are visible to the general public.
[ x] I have read the Bioconductor Package Submission instructions. My package is consistent with the Bioconductor Package Guidelines.
[ x] I understand Bioconductor Package Naming Policy and acknowledge Bioconductor may retain use of package name.
[ x] I understand that a minimum requirement for package acceptance is to pass R CMD check and R CMD BiocCheck with no ERROR or WARNINGS. Passing these checks does not result in automatic acceptance. The package will then undergo a formal review and recommendations for acceptance regarding other Bioconductor standards will be addressed.
[ x] My package addresses statistical or bioinformatic issues related to the analysis and comprehension of high throughput genomic data.
[ x] I am committed to the long-term maintenance of my package. This includes monitoring the support site for issues that users may have, subscribing to the bioc-devel mailing list to stay aware of developments in the Bioconductor community, responding promptly to requests for updates from the Core team in response to changes in R or underlying software.
[ x] I am familiar with the Bioconductor code of conduct and agree to abide by it.
I am familiar with the essential aspects of Bioconductor software management, including:
For questions/help about the submission process, including questions about the output of the automatic reports generated by the SPB (Single Package Builder), please use the #package-submission channel of our Community Slack. Follow the link on the home page of the Bioconductor website to sign up.