A recent discussion (libscran/scrapper#21) got me thinking about the accessibility of BioC-devel packages. Specifically, in the Oct-to-Apr period, BioC-devel becomes much harder to use as it relies on R-devel. Of course, I understand why this is the way it is. However, it does mean that "regular people" (i.e., not R developers) wanting to use the cutting-edge versions of Bioconductor packages do not have an easy path forward. Either they have to grapple with installing R-devel, which may not be easy on centrally administered systems (e.g., HPCs); or they try to manually install all of the BioC-devel packages from source on the latest release version of R.
Perhaps an easy fix - at least for installation from source - is to add an option to BiocManager::install() to permit use of the latest R release instead of R-devel when version="devel". This would greatly improve accessibility as people could reasonably be expected to have the latest release of R; it would make the BioC-devel experience during Oct-to-Apr more consistent with that of Apr-to-Oct; and it probably wouldn't be too bad w.r.t. compatibility as there aren't usually many breaking changes between two consecutive R versions.
This option should be an explicit choice so the user knows that they are signing up to something that may or may not work, just in case any of their desired BioC-devel packages actually does depend on R-devel features. Maybe with some warnings or messages as well to really remind the user that their mileage may vary. But, at the very least, it would provide an okay-ish pathway for users who want to use BioC-devel and would otherwise be manually installing the development versions of packages from GitHub into their R-release (and subsequently mixing and matching BioC-devel and release packages, with all of the associated headaches).
For binary packages, I don't know if they are compatible between R minor versions. I suppose CRAN has oldrel for a reason. Possibly install() could just revert to installing from source if the proposed option is set, which is not particularly accessible but oh well. I'd speculate that using BioC-devel + R-devel is actually easier for Mac/Windows users as these operating systems are more likely to be on personal machines where the user is allowed to install their own software, rather than trying to cajole their IT team to do it.
A recent discussion (libscran/scrapper#21) got me thinking about the accessibility of BioC-devel packages. Specifically, in the Oct-to-Apr period, BioC-devel becomes much harder to use as it relies on R-devel. Of course, I understand why this is the way it is. However, it does mean that "regular people" (i.e., not R developers) wanting to use the cutting-edge versions of Bioconductor packages do not have an easy path forward. Either they have to grapple with installing R-devel, which may not be easy on centrally administered systems (e.g., HPCs); or they try to manually install all of the BioC-devel packages from source on the latest release version of R.
Perhaps an easy fix - at least for installation from source - is to add an option to
BiocManager::install()to permit use of the latest R release instead of R-devel whenversion="devel". This would greatly improve accessibility as people could reasonably be expected to have the latest release of R; it would make the BioC-devel experience during Oct-to-Apr more consistent with that of Apr-to-Oct; and it probably wouldn't be too bad w.r.t. compatibility as there aren't usually many breaking changes between two consecutive R versions.This option should be an explicit choice so the user knows that they are signing up to something that may or may not work, just in case any of their desired BioC-devel packages actually does depend on R-devel features. Maybe with some warnings or messages as well to really remind the user that their mileage may vary. But, at the very least, it would provide an okay-ish pathway for users who want to use BioC-devel and would otherwise be manually installing the development versions of packages from GitHub into their R-release (and subsequently mixing and matching BioC-devel and release packages, with all of the associated headaches).
For binary packages, I don't know if they are compatible between R minor versions. I suppose CRAN has
oldrelfor a reason. Possiblyinstall()could just revert to installing from source if the proposed option is set, which is not particularly accessible but oh well. I'd speculate that using BioC-devel + R-devel is actually easier for Mac/Windows users as these operating systems are more likely to be on personal machines where the user is allowed to install their own software, rather than trying to cajole their IT team to do it.