Dan, Thanks for the quick response. Unfortunately I am hoping for something I can access with base R, including older versions, which precludes https and curl. Is there any way to have a public facing url that hosts that file, or a webservice which returns it directly?
Best, ~G On Wed, May 27, 2015 at 10:47 AM, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > > > ----- Original Message ----- > > From: "Gabe Becker" <becker.g...@gene.com> > > To: bioc-devel@r-project.org > > Cc: "csardi gabor" <csardi.ga...@gmail.com> > > Sent: Wednesday, May 27, 2015 10:31:43 AM > > Subject: [Bioc-devel] Meta-information about bioc and bioc-package > releases > > > > Hey all, > > > > I've been wondering if bioc could offer a way to query information > > about > > itself similar - though not necessarily identical - to what Gabor > > Csardi's > > (cc'ed) crandb offers http://www.r-pkg.org/services#api > > <http://www.r-pkg.org/services#api> > > > > Basically, I would really like two things, in increasing order of > > difficulty: > > > > #1: A webservice to easily determine the Bioc release version > > associated > > with a particular version of R. > > > > R knows how to do this itself, but it doesn't share the wealth > > (function > > not exported) so I can't get at that without a NOTE which blocks > > submission > > to CRAN. > > > > Here's a web service to do this: > > curl -u readonly:readonly > https://hedgehog.fhcrc.org/bioconductor/trunk/bioconductor.org/config.yaml > > This returns a yaml file containing a list/hash called > "r_ver_for_bioc_ver". It also contains the current release > ("release_version") and devel ("devel_version") of Bioconductor. Putting > this information together you should be able to > determine what you want. > > > > > Note that I explicitly do not want to require or depend on the > > presence of > > BiocInstaller. Depending on BiocInstaller would prevent switchr from > > allowing context switching between Bioc versions, which is a major > > use-case > > for the software. > > > > Something as simple as a web service which accepts an R version > > string and > > spits out the Bioc release number would be sufficient, though a way > > to get > > the full repo URLs would be a nice bonus > > > > #2: A crandb-like database of Bioc package version releases. > > > > The queries that I would specifically like, in the context of > > reproducibility with my switchr package, are: > > > > > > - Which exact package versions were available on a specific date > > - Start and end dates for a given release of bioc > > - What date was a specific package version first released, and the > > span > > dates it was available via (a) repo > > - Dependency and reverse dependency information for each release > > of each > > package > > - Given a package version, the smallest set of packages necessary > > to > > install the package, and the versions of those dependencies that > > were > > concurrent with the initial release, midpoint, and last moment > > before being > > superceded for the package in question. (crandb does not offer > > this; I can > > do it with many seperate calls, but it seems like the computation > > should be > > server-side for this). Peferably with or without including > > Suggests. > > Depending on implementation this could be completely or partially > > pre-computed for efficiency. > > - A mapping from package versions in repositories to SVN branch > > and > > commit, if possible. > > - Possibly other stuff crandb tracks. > > > > Would one or both of these be possible? > > > > I looked at using the crandb code directly, but it pulls from > > <cranmirror>/src/contrib/Meta/archive.rds to get all of this > > information, > > and that file either doesn't exist or isn't readable in the Bioc > > repositories. If we were to change that, I think a lot of what > > crandb > > offers would come nearly for free, the only work being adding things > > that > > crandb doesn't offer (the tree-shaking and version to svn mapping, > > for > > example). > > I'm not sure how the Meta/archive.rds file is generated; do you know? > > As for the other requests, we'll need to discuss this stuff internally > before responding further. > > Dan > > > > > > > Best > > ~G > > > > -- > > Gabriel Becker, Ph.D > > Computational Biologist > > Genentech Research > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > Bioc-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > -- Gabriel Becker, Ph.D Computational Biologist Genentech Research [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
