-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make BiocManager work for a version of Bioconductor that doesn't "officially exist" yet #46
Comments
Running into this again (using R 4.0):
If BiocVersion says this is BioC 3.11 and This is breaking the scripts we use for generating the 3.11 build report and propagating packages. The scripts need to access the 3.11 repositories to see what's already there in order to decide what to propagate or not. Seems natural to use Thanks! |
It would be nice to get this out of the way before the next Bioconductor release. I hope it's a reasonable request. Thanks! |
I'm concerned that this would allow the user to have an invalid installation where BIocVersion implies an unsupported version. |
Let's see if we are on the same page:
The change I'm proposing will only have an effect during the 24h window during which it's important that BiocManager works properly with the new BiocVersion. It won't change anything outside this 24h window. |
I understand the intention of the issue. The implementation would either make a general exception (once BiocVersion is found, the version is assumed to be valid) or require elaborate conditional code to know that the installed version is leading the version in config.yaml in a valid way. If the build system has special requirements, shouldn't the build system implement the solution? |
The proposed change would benefit not only the build system but anybody who installs the new BiocVersion during the 24h window.
The easier way to go is to replace the error by a warning. So a 1-word change only. The change would only be noticeable during the 24h window. |
Also it's important to understand that all the package failures we see during the last run of the devel builds that precedes a release are because these packages contain code that uses BiocManager but BiocManager refuses to work. Not sure how the build system could implement a solution for that. To make things even worse, these failures cannot even be reproduced because the 24h window ends soon after the report is published and BiocManager typically starts to work normally again at the end of the window (it starts to work again when the new devel branch becomes official). FWIW the BBS code itself was using |
So we have a bunch of failures on the BioC 3.10 report today because BiocManager is complaining with:
That's because the build system installed the new BiocVersion (3.10.0) at the beginning of the builds yesterday. Then later during the
R CMD build
andR CMD check
stages of the builds BiocManager detected that BioC 3.10 was being used and didn't like it.This affected 19 packages on all platforms:
This could be avoided by having
BiocManager::version()
andBiocManager::repositories()
"work" as long as BiocVersion is installed. This would also address other problems we've seen earlier like Marcel's inability to use BioC 3.10 yesterday, or the problem with theBBS/utils/createPropagationDB.R
script that broke this afternoon when trying to generate the propagation DB at the end of the BioC 3.10 builds.Even if the config files at bioconductor.org didn't officially acknowledge its existence until today, BioC 3.10 started to "exist" when we branched yesterday. Furthermore, the 3.10 repos have been available (and populated) for the last 2 weeks and there is no reason why BiocManager couldn't have been used to install stuff from these repos. When the repos are not yet available,
BiocManager::install()
would emit a warning (it would be the warning coming frominstall.packages()
) and wouldn't be able to install anything, butBiocManager::version()
andBiocManager::repositories()
would still work.Is that a reasonable request?
Thanks!
The text was updated successfully, but these errors were encountered: