Question: Package archive for the purpose of reproducible research
gravatar for robert.bruccoleri
2.2 years ago by
United States
robert.bruccoleri10 wrote:

I am helping a group of statistical and genetic analysts maintain an R environment for their work. One key capability that is required is the ability to reproduce previous computations. The R packages that were used for an analysis are typically recorded.

For CRAN, it's easy to find the tar-ball for any published version of any package, but that is not the case of Bioconductor. The directories that contain tar-balls for versions between releases are not indexed, so the only way to find a specific version is to try the URL, which is really inefficient and not practical.

Would the Bioconductor developers please consider making all published tar-balls available in some easy to find way? I understand the need for having a consistent set of packages so incompatibilities are avoided, but the current situation makes it very difficult for those of us facing an auditor who wants us to reproduce a five year old computation.

One suggestion that I could offer would be to put the tarballs archive behind a user account system (as is used by this forum for posting messages) and have the user see a clear statement that the tarballs outside of releases are not supported or recommended in any way.


ADD COMMENTlink modified 2.2 years ago by Martin Morgan ♦♦ 21k • written 2.2 years ago by robert.bruccoleri10
gravatar for Martin Morgan
2.2 years ago by
Martin Morgan ♦♦ 21k
United States
Martin Morgan ♦♦ 21k wrote:

This is a relatively regular request (most recently on Bioc-devel), with different possible solutions. Tar balls represent one solution. Another is to tag package versions in source code repositories. There are several additional schemes to save R archives, including packrat and switchr. This will eventually be addressed, but is not at the top of our priority list.

Generally, the 'final' version of a package for a Bioconductor release is available at a url with path /packages/<bioc-version>/<package-name>, e.g., Each release is a CRAN-style repository, so the content of the release can be discovered at, e.g., using read.dcf(url()). And using biocLite() as documented on each package landing page with the appropriate version of R (and BIocInstaller, for more recent releases) consults this repository.

The tar.gz archive is unlikely to be sufficient for reproducibility five years from now -- compilers and operating system dependencies will have changed by then. This implies that the user has maintained this part of the infrastructure, and that generally reproducibility is really in the hands of the user and their specific systems -- having tarballs available will be of little value.

Exact reproducitbility is a starting point for validating an analysis, but the scientific case for reproducing an incorrect analysis [reflected in .z versions other than the final x.y.z within a Bioconductor release] is not particularly compelling.

I opened a github issue for this on our 'BBS' (Bioconductor build system) software; you and others are welcome to augment the issue with specific suggestions (and of course 'patches welcome', though that would be challenging in the present case).

ADD COMMENTlink written 2.2 years ago by Martin Morgan ♦♦ 21k

The value of having specific versions available (as reported by sessionInfo) should not be discounted.

In the face of a data quality audit where a prior result is failing to reproduce, being able to eliminate version x.y.z differences as a source of the failure to reproduce would be very compelling and valuable!

Going forward, a simple solution would be to just save the tar-balls in a CRAN like archive.

ADD REPLYlink written 2.2 years ago by robert.bruccoleri10
Please log in to add an answer.


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