[Bioc-devel] Meta-information about bioc and bioc-package releases
becker.gabe at gene.com
Thu May 28 00:32:35 CEST 2015
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?
On Wed, May 27, 2015 at 10:47 AM, Dan Tenenbaum <dtenenba at fredhutch.org>
> ----- Original Message -----
> > From: "Gabe Becker" <becker.gabe at gene.com>
> > To: bioc-devel at r-project.org
> > Cc: "csardi gabor" <csardi.gabor at gmail.com>
> > Sent: Wednesday, May 27, 2015 10:31:43 AM
> > Subject: [Bioc-devel] Meta-information about bioc and bioc-package
> > 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
> 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.
> > Best
> > ~G
> > --
> > Gabriel Becker, Ph.D
> > Computational Biologist
> > Genentech Research
> > [[alternative HTML version deleted]]
> > _______________________________________________
> > Bioc-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
Gabriel Becker, Ph.D
[[alternative HTML version deleted]]
More information about the Bioc-devel