[Bioc-devel] Tracking Current release (http://www.bioconductor.org/packages/current redirect to http://www.bioconductor.org/packages/2.14)

[Steve Lianoglou]

Hi,

Why not take the following links a bit further:

http://bioconductor.org/js/versions.js
http://bioconductor.org/bioc-version

And just have something that returns a JSON response with more detail
... perhaps something like:

{
  "R2_0": { ... },
  "R2_15": {"release": 2.12, "devel": 2.13},
  "R3_0": { "release": 2.13, "devel": 2.14},
  "R3_1": { "release": 2.14, "devel": 3.0},
  // someway to identify R-devel
  "R-devel??": { ... }
}

And maybe put some utility function in BiocInstaller to parse that. If
you're feeling ambitious, you could go down to the R3_0_2 level of
granularity, I guess.

Just a thought,
-steve


On Wed, May 7, 2014 at 10:57 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:
>
>
> ----- Original Message -----
>> From: "Martin Morgan" <mtmorgan at fhcrc.org>
>> To: bioc-devel at r-project.org
>> Sent: Wednesday, May 7, 2014 10:07:10 PM
>> Subject: Re: [Bioc-devel] Tracking Current release (http://www.bioconductor.org/packages/current redirect to
>> http://www.bioconductor.org/packages/2.14)
>>
>> Hi Don --
>>
>> On 05/07/2014 06:21 PM, Don Armstrong wrote:
>> > I maintain a collection of Debian packages of CRAN and BioC[1] for
>> > public use; currently, whenever BioC makes a new release, it
>> > requires
>> > manual intervention for me to point at the new release location.
>> >
>> > It would be helpful if there was a
>> > http://www.bioconductor.org/packages/current redirect to the
>> > current
>> > release, or if there was another easily parsable method to obtain
>> > the
>> > current bioC release version.
>>
>> Bioconductor releases are tied to R versions and the 'current' Bioc
>> for a
>> particular R, in a brand new installation, is
>>
>>    source("http://bioconductor.org/biocLite.R")
>>    biocVersion()
>>
>> (this is BiocInstaller::biocVersion(), where the biocLite.R script
>> has arranged,
>> modulo MITM concerns below, to install the version of the
>> BiocInstaller package
>> relevant to your version of R). I personally think of this as the
>> canonical
>> location, but...
>>
>> http://bioconductor.org/packages/release goes to the current release
>> 'biocViews', with packages under release/ being the current release
>> versions.
>> http://bioconductor.org/bioc-version is probably what you'll end up
>> using
>> (though I believe it's hand curated), and
>
>
> This is automatically generated, as is
> http://bioconductor.org/js/versions.js
> which also includes the devel version number.
>
> Dan
>
>> tools:::.BioC_version_associated_with_R_version (this is a function
>> in R-3.1)
>> gives the version that R thinks is the current BioC version (this can
>> become
>> stale, e.g., R-3.0.1 was released when BioC-2.12 was the current
>> version, but
>> part way through the R point release BioC 2.13 became available [or
>> at least,
>> that's how I remember it]).
>>
>> > FWICT, neither http://bioconductor.org/getBioC.R nor
>> > http://bioconductor.org/biocLite.R encode that information
>> > either,[2]
>> > unless that's what CURRENT_R_DEVEL_VERSION <- "2.14.0" is supposed
>> > to
>> > be.
>> >
>> >
>> > 1: http://debian-r.debian.net/
>> >
>> > 2: I should also point out that the current methodology of
>> > installing
>> > BioC using code from a remote host is problematic as it exposes
>> > users to
>> > MITM attacks because it is never checked for authenticity via PGP
>> > or at
>> > the very least, SSL. As such, sourcing that script and using
>> > variables
>> > populated by it isn't really acceptable.
>>
>> Of course this is a valid concern and we can work toward a more
>> secure approach.
>>
>> Perhaps I could take the opportunity to ask a naive question about
>> debian binary
>> distributions of R. What is the directory into which packages are
>> installed by
>> sudo? In particular, are they unversioned, /usr/lib/R/library etc, as
>> opposed to
>> say /usr/lib/R-3.1/library ? I'm asking because a number of users
>> seem to show
>> up with say R-3.1 reporting a mix of R-3.1 and R-3.0.2 packages,
>> usually to ill
>> effect; this is not necessarily likely for user-installed packages,
>> because the
>> system directories won't be writeable and R will prompt with a
>> versioned
>> directory ~/R/x86_64-unknown-linux-gnu-library/3.1 as the location to
>> install
>> libraries. I'm wondering if mixed package versions would happen if
>> their package
>> manager failed to remove previously installed packages from the
>> /usr/lib/R/library directory, or if the user installed multiple
>> versions of R.
>> Of course this could merely reflect users installing R without the
>> help of
>> package managers, and either way it might point to changes in the way
>> R installs
>> itself.
>>
>> Martin
>>
>> >
>>
>>
>> --
>> Computational Biology / Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N.
>> PO Box 19024 Seattle, WA 98109
>>
>> Location: Arnold Building M1 B861
>> Phone: (206) 667-2793
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



-- 
Steve Lianoglou
Computational Biologist
Genentech