Question: Problem using GOTERM[["x"]] from GO.db
gravatar for karl.stamm
20 months ago by
United States
karl.stamm10 wrote:

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 ? 

go.db • 1.3k views
ADD COMMENTlink modified 20 months ago by Martin Morgan ♦♦ 24k • written 20 months ago by karl.stamm10
Answer: Problem using GOTERM[["x"]] from GO.db
gravatar for Martin Morgan
20 months ago by
Martin Morgan ♦♦ 24k
United States
Martin Morgan ♦♦ 24k wrote:

Yes RSQLite made an incompatible change. Either revert to a previous version of RSQLite, wait until tomorrow and update AnnotationDbi via biocLite("AnnotationDbi"), or update now from github using biocLite("Bioconductor/AnnotationDbi", ref = "..."), where ref is "master" (if you are using 'bioc devel', or "RELEASE_3_7". If you're using a version of Bioconductor before version 3.7, you will unfortunately have to update to version 3.7 to obtain a patched version of AnnotationDbi.

ADD COMMENTlink modified 20 months ago • written 20 months ago by Martin Morgan ♦♦ 24k

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.

ADD REPLYlink written 20 months ago by Robert Castelo2.4k

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.

ADD REPLYlink written 20 months ago by Martin Morgan ♦♦ 24k

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.

ADD REPLYlink written 20 months ago by Robert Castelo2.4k

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.

ADD REPLYlink written 20 months ago by Martin Morgan ♦♦ 24k

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.

ADD REPLYlink written 20 months ago by Robert Castelo2.4k

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.

ADD REPLYlink written 20 months ago by Martin Morgan ♦♦ 24k

Excellent suggestion, thanks!

ADD REPLYlink written 20 months ago by Robert Castelo2.4k
Please log in to add an answer.


Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 443 users visited in the last hour