Hi,
I recently received the following e-mail from Professor Ripley:
---
DELETED -- PLEASE DO NOT POST PRIVATE EMAIL WITHOUT PERMISSION
---
However, I'd much prefer to have the current version of my package available for older versions of R, while using BiocInstaller / BiocManager as needed (and appropriate) for the version of R used by the user. Is there a recommended way to accomplish this?
Thanks,
Kevin
I believe, though it would be more effective to communicate with CRAN directly, that the intention was to alert you to a problem that your R-devel users will experience when BiocInstaller is no longer available, with the recommendation to handle the situation gracefully rather than with an error.
if (requireNamespace("BiocInstaller") {
...
} else {
...
}
I do not think there is a concern with BiocInstaller being in Enhances:, but again this is something that CRAN can clarify.
Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
version 2.3.6
BiocInstaller will still be available for older versions of R but will be defunct as of Bioconductor 3.9 (compatible with R 3.6.0). BiocInstaller and BiocManager both manage package versions similarly, ensuring that the version of the packages being used are compatible with the version of R and Bioconductor being utilized.
I'm not really sure about CRAN rules, but it would seem like BiocInstaller could go in Suggests: (if CRAN does not require Suggest:ed package to be installed) or perhaps Enhances: (I'm not sure how this will play with CRAN either). If others have experience it would be great to hear...
CRAN does allow you to have BiocInstaller in Suggests, this is what I am doing in devtools, and did not receive this note from Prof. Ripley for devtools.
However this means all packages that wish to support R < 3.5 need to include code to conditionally use either BiocManager or BiocInstaller depending on the version of R.
It would be ideal for package authors to instead rely solely on BiocManager for all versions of R, avoiding the maintenance burden of using two different packages.
BiocManager actually has a second component, the Bioconductor BiocVersion package. As you know, Bioconductor has two releases per year, whereas CRAN has only one. There is therefore a need to store the version of Bioconductor in use, from the two available for R, in a particular R session. This is the role played by BiocVersion.
So for instance in R 3.5, a user with BiocVersion 3.7 installed signals to BiocManager to install Bioconductor packages from the 3.7 repository, whereas a user with BiocVersion 3.8 gets Bioconductor packages from the 3.8 repository.
BiocVersion was introduced with Bioconductor 3.7. It follows that BiocManager cannot work with earlier Bioconductor releases because BiocManager as no way to know what version of Bioconductor the user wishes to use.
I suppose BiocManager could as a fall-back and when R is < 3.5 look for and use BiocInstaller::biocVersion(), but to me this seems out-of-scope for what BiocManager is advertised to do, which is to install Bioconductor packages in R version 3.5 and higher. It also adds code complexity, which had become a liability in BiocInstaller and the biocLite script before that.
I do have two concerns that I'll mention. It is true that I added, a little abruptly, the condition that BiocInstaller depend on R < 3.6.0. This has caused some problems, but I feel like it forces a solution that is 'up front' rather than allowing mistakes (e.g., thinking that BiocInstaller can be used in R >= 3.6) from persisting for a longer time.
A second problem, closely related to the discussion here, is that users of R < 3.5.0 googling for a Bioconductor package will find themselves on the current landing page with instructions to use BiocManager(), and these instructions will fail because BiocManager is not available for their R. There are old landing pages (e.g., https://bioconductor.org/packages/3.6/DESeq2 ) with correct instructions as well as 'legacy' installation instructions, but we should certainly try to make this self-discovery less painful.
FWIW, in Packrat's case, BiocInstaller already was in Enhances. My current plan is to just hide the dependency from CRAN altogether and implicitly call requireNamespace() and asNamespace() behind the scenes to load the package opportunistically when available. This isn't great, but I don't see a better way forward.