Entering edit mode
I maintain "rgsepd" which uses "DESeq2" and "goseq" to run an annotation pipeline. Internally, when I have a character representation of a GO term I'm interested in more information about, I use the list interface (double-bracket) to a global exported by the GO.db library.
The command GOTERM[["GO:0034599"]] used to return to me an object with with slots like Term, Ontology, and Definition. Now I'm getting an error condition
Error in initialize(value, ...) :
argument "go_id" is missing, with no default
Which looks like either a bug or the API has moved out from under me. Has anyone else used GOTERM[[]] or know what I can do to get my package running again ?
Martin, AnnotationDbi is a package very upstream in the Bioconductor infrastructure, you need to scroll down quite a bit through its landing web page to see all packages that either depend, import or suggest it. So, such an error essentially breaks the functionality of a large part of BioC packages. I know that we should always switch to the latest release but in my experience, there are a number of reasons why this cannot be immediately done, ranging from the difficulty to have university IT services to update software for teaching, to complex research workflows that you may want to update on a particular (later) time-point to have a smooth transition. While downgrading the problematic package upstream is the solution, sometimes this can be also difficult depending on the IT organization handling the software. So, I wanted to suggest whether it could be possible for upstream packages with lots of reverse dependencies, such as AnnotationDbi, to depend on fixed versions of packages, i.e., RSQLite (=x.x.x), etc., to avoid updates that break their functionality and only change the version of this dependency when strictly necessary.
Herve opened a github issue on RSQLite; I think this is a significant oversight on the maintainer's part.
If it's difficult to update packages, then RSQLite would not have been updated and downstream packages not broken?
I'm not really sure how R works with specific version dependencies -- does install.packages() just fail with 'version not available'? I don't know that there are provisions to have multiple versions in a single library, so there would need to be quite a bit of intentionality (e.g., with separate .libPaths() for different package versions) on the part of the administrator. I'm willing to be educated here, so insights welcome.
I see, thanks for the further info about RSQLite, it's certainly bad luck that this didn't happen just a few weeks before, on time to fix both releases 3.6 and 3.7. I did not want to say that updating packages is difficult, but that either updating R or downgrading packages, may be difficult, surely not for me, but for certain IT infrastructure for computer rooms for teaching, or for students working with their own laptops with little experience in R.
I do not know either how R works with specific version dependencies but I think that having some control on the "eligibile" versions of package dependencies outside Bioconductor could help having legacy BioC releases surviving over longer periods of time, which would be good not only for the situations I described before but also for reproducibility purposes.
I appreciate the suggestion and it would be great to make versioning more robust.
It's tricky to know when to lock down a version. For instance if we'd made pre-release AnnotationDbi depend on a specific version of RSQLite, then those legacy versions would have broken when the new RSQLite came out and administrators updated, which is what happened anyway! On the other hand we might have locked a specific version of say RCurl, and then a compatible release of RCurl would break installations unnecessarily. And we can't really do things retrospectively, either, freezing an old AnnotationDbi's dependency once a breaking change occurs... In all cases it seems like fairly sophisticated system administration (including knowledge of R and Bioconductor versioning and release schemes) will be required to manage separate dependencies for each package.
I guess I'm missing something important here, but if AnnotationDbi would depend on a specific version of RSQLite, I thought (or rather I wished!) that R would not let updating RSQLite. Presumably, looking up reverse dependencies with specific versions is time consuming. So, in the end, containerization is probably the only solution.
I confirmed that if one downgrades RSQLite and installs a version of AnnotationDbi with an exact dependency, then invoking update.packages() (or biocLite()) will prompt to update RSQLite, regardless of the AnnotationDbi constraint. Once RSQLite is updated, library(AnnotationDbi) with its exact dependency fails.
A different solution to reproducibility, not impossible in a shared environment, is to install all libraries other than base into a path set by R_LIBS_USER (or generally the first path in .libPaths()). When you're satisfied or want to 'lock down' the dependencies (e.g., at the end of Bioconductor release), use the file system to make the R_LIBS_USER directory unwriteable. Make an alias or other shortcut so that BioC2.6 or whatever points to the correct library and R. And of course there are various schemes like MRAN, switchr, etc.
Excellent suggestion, thanks!