[Bioc-devel] Short URLs for packages?

Dan Tenenbaum dtenenba at fredhutch.org
Wed Jul 8 20:19:25 CEST 2015 


----- Original Message -----
> From: "Vincent Carey" <stvjc at channing.harvard.edu>
> To: "Dan Tenenbaum" <dtenenba at fredhutch.org>
> Cc: "Tim Triche, Jr." <ttriche at usc.edu>, bioc-devel at r-project.org, "Gabe Becker" <becker.gabe at gene.com>, "Martin
> Morgan" <mtmorgan at fredhutch.org>
> Sent: Tuesday, July 7, 2015 1:12:26 PM
> Subject: Re: [Bioc-devel] Short URLs for packages?
> 
> 
> OK, thanks. Should we add a little bit to each package landing page
> indicating how to link?
> 
> 

Done. For example go to http://bioconductor.org/packages/release/bioc/html/a4.html and scroll to the bottom, the short url appears just before "Package Download Stats".

Dan


> On Tue, Jul 7, 2015 at 3:52 PM, Dan Tenenbaum <
> dtenenba at fredhutch.org > wrote:
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Vincent Carey" < stvjc at channing.harvard.edu >
> > To: "Martin Morgan" < mtmorgan at fredhutch.org >
> > Cc: "Tim Triche, Jr." < ttriche at usc.edu >, bioc-devel at r-project.org
> > , "Gabe Becker" < becker.gabe at gene.com >
> > Sent: Tuesday, July 7, 2015 12:49:24 PM
> > Subject: Re: [Bioc-devel] Short URLs for packages?
> > 
> > Has there been a solution to the short URL question?
> > 
> 
> Yes: https://stat.ethz.ch/pipermail/bioc-devel/2015-April/007464.html
> 
> Dan
> 
> 
> 
> 
> > On Tue, Mar 24, 2015 at 7:14 AM, Martin Morgan
> > < mtmorgan at fredhutch.org >
> > wrote:
> > 
> > > On 03/24/2015 02:31 AM, Wolfgang Huber wrote:
> > > 
> > >> Before we start a religious war, can we make progress on the
> > >> pragmatic
> > >> goal of making it possible to provide such URLs to people?
> > >> 
> > >> There are two concepts
> > >> - ‘the package' - a specific version, running in a specific
> > >> environment,
> > >> ‘frozen’, etc. (Gabe)
> > >> - ‘the package’ - as a concept and a living artifact (me, Bernd,
> > >> Tim)
> > >> Both are useful. And having URLs for both would also be useful.
> > >> 
> > > 
> > > 0. That's (mostly) satisfied with the current scheme and
> > > 
> > > http://bioconductor.org/packages/3.0/bioc/html/BiocGenerics.html
> > > http://bioconductor.org/packages/release/bioc/html/BiocGenerics.html
> > > http://bioconductor.org/packages/devel/bioc/html/BiocGenerics.html
> > > 
> > > (hey, no www. -- that's four letters already! Perhaps
> > > importantly,
> > > there's
> > > also a hard-coded version for devel, 3.1, and for past releases.
> > > So
> > > as I
> > > understand it the request is for (a) shorter path names and (b)
> > > dynamic
> > > selection of release vs. devel, mentioned below, for the <6 month
> > > period
> > > when the package is in devel but not yet release. Also noted is
> > > Henrik's
> > > earlier proposal mentioned by Sean.
> > > 
> > > 
> > > 1. 'packages', 'bioc', 'html' all look somehow redundant, so
> > > 
> > > http://bioconductor.org/release/BiocGenerics.html
> > > http://bioconductor.org/devel/BiocGenerics.html
> > > http://bioconductor.org/3.0/BiocGenerics.html
> > > 
> > > but also
> > > 
> > > http://bioconductor.org/release/BiocGenerics/ (implicit
> > > index.html)
> > > http://bioconductor.org/BiocGenerics/release/
> > > 
> > > and their devel and version counterparts would seem quite
> > > possible
> > > / not
> > > profoundly controversial. Landing pages for specific versions
> > > 3.22.7 do
> > > not currently exist, change little across package minor versions,
> > > and would
> > > not lead to packages installable via biocLite(), so this idea of
> > > Tim's is a
> > > non-starter in my opinion.
> > > 
> > > Having the 'version' level of the path before the package
> > > provides
> > > a
> > > logical place to put biocViews for that release. I'd vote for one
> > > of the
> > > release/BiocGenerics[.html] schemes.
> > > 
> > > 
> > > 2. Something like
> > > 
> > > http://bioconductor.org/BiocGenerics
> > > 
> > > redirecting to release when available, devel when newly added
> > > (Wolfgang's
> > > proposal) would in my opinion be confusing, especially since we
> > > continue to
> > > have so much difficulty with version mismatches in user
> > > installations. I
> > > don't think having a warning on redirect that 'this package is
> > > not
> > > available for release' would be effective either at advertising
> > > robust
> > > software or at enabling use by comparatively naive users.
> > > 
> > > 
> > > 3. In terms of the 'redundant' parts of the path, these are not
> > > completely
> > > arbitrary (not that these considerations have to dictate
> > > presentation; they
> > > do make one suspect that 'add a redirect and everything will be
> > > fine' will
> > > result in a nice plate of spaghetti, especially if there is some
> > > desire to
> > > retain backward compatibility).
> > > 
> > > 'packages' separates the package repository from other aspects of
> > > bioconductor.org , and group related concepts ('package', 'help',
> > > etc.) at
> > > a similar hierarchical level.
> > > 
> > > 'bioc' serves to distinguish between software ('bioc/'),
> > > annotation
> > > ('data/annotation') and experiment data ('data/experiment')
> > > packages, and
> > > these divide the overall repository into three for the purposes
> > > of
> > > biocLite() / install.packages() (this conceptual distinction has
> > > been
> > > useful, I think).
> > > 
> > > > biocinstallRepos()
> > > BioCsoft
> > > " http://bioconductor.org/packages/3.1/bioc "
> > > BioCann
> > > " http://bioconductor.org/packages/3.1/data/annotation "
> > > BioCexp
> > > " http://bioconductor.org/packages/3.1/data/experiment "
> > > 
> > > 'html' distinguishes the landing pages from the package tar balls
> > > /
> > > binary
> > > distributions themselves as returned by
> > > contrib.url(biocinstallRepos()),
> > > and from their vignette/, man/ and news/ resources.
> > > 
> > > 
> > > 4. In terms of best practices, it seems like articles are about
> > > particular
> > > versions and should cite the package as such, for instance if
> > > only
> > > in devel
> > > when the paper is being written as .../3.1/..., but that there is
> > > no
> > > substantive cost to also referencing 'current version available
> > > [after
> > > April, 2015] at .../release/....
> > > 
> > > 
> > > 5. At the end of the day I find myself casting my lot for landing
> > > pages
> > > with the form
> > > 
> > > http://bioconductor.org/release/BiocGenerics/
> > > 
> > > which leads to a little less typing but not the dynamic
> > > resolution
> > > that
> > > started this (version) of the thread.
> > > 
> > > 
> > > Martin
> > > 
> > > 
> > > 
> > >> Wolfgang
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> On Mar 23, 2015, at 18:43 GMT+1, Tim Triche, Jr.
> > >> < tim.triche at gmail.com >
> > >>> wrote:
> > >>> 
> > >>> I just meant that the mnemonic link
> > >>> 
> > >>> http://www.bioconductor.org/limma/ (SEO version of limma ;-))
> > >>> 
> > >>> could dump people at something like
> > >>> 
> > >>> http://www.bioconductor.org/release/limma/3.22.7/ (I'd prefer
> > >>> this)
> > >>> 
> > >>> or if need be for backwards compatibility,
> > >>> 
> > >>> http://www.bioconductor.org/packages/3.0/limma/3.22.7/ (seems
> > >>> less
> > >>> good)
> > >>> 
> > >>> instead of
> > >>> 
> > >>> http://www.bioconductor.org/packages/3.0/bioc/html/limma.html
> > >>> (current)
> > >>> 
> > >>> and furthermore the specific version page could note more
> > >>> prominently
> > >>> that
> > >>> the build of limma being referenced at that particular instance
> > >>> in time
> > >>> may
> > >>> or may not be the same as was cited in a paper, used in an
> > >>> analysis,
> > >>> available for download the previous evening, etc. thus
> > >>> citation("limma")
> > >>> is
> > >>> a Very Good Idea when writing up results that depend upon it.
> > >>> Because
> > >>> even
> > >>> the WEHI guys could theoretically have a bug that impacted
> > >>> someone's
> > >>> results (as opposed to the usual case of Didn't Read The Fine
> > >>> Limma
> > >>> Manual)
> > >>> 
> > >>> Does that make more sense? (Probably not, but worth a try)
> > >>> 
> > >>> Statistics is the grammar of science.
> > >>> Karl Pearson
> > >>> < http://en.wikipedia.org/wiki/The_Grammar_of_Science >
> > >>> 
> > >>> On Mon, Mar 23, 2015 at 9:29 AM, Dan Tenenbaum
> > >>> < dtenenba at fredhutch.org >
> > >>> wrote:
> > >>> 
> > >>> 
> > >>>> 
> > >>>> On March 23, 2015 9:18:57 AM PDT, "Tim Triche, Jr." <
> > >>>> tim.triche at gmail.com >
> > >>>> wrote:
> > >>>> 
> > >>>>> 
> > >>>>> Packages are (read: should be, IMHO) published, citable
> > >>>>> pieces
> > >>>>> of
> > >>>>>> 
> > >>>>> research, though. Imagine if a paper you cite were silently
> > >>>>> updated
> > >>>>> without the doi/citation changing. That wouldn't be good
> > >>>>> 
> > >>>>> I don't disagree, but the existing setup does nothing to
> > >>>>> address that.
> > >>>>> Citation('limma'), for example, does.
> > >>>>> 
> > >>>>> .../release/... and .../devel/... can change at any time,
> > >>>>> potentially
> > >>>>> overnight (with or without a new BioC release). The only real
> > >>>>> way to
> > >>>>> cite an exact version is to cite that exact version, which is
> > >>>>> already
> > >>>>> the proper way to do things and would remain unaffected by
> > >>>>> this, at
> > >>>>> least AFAIK.
> > >>>>> 
> > >>>>> Perhaps a useful addendum would be for the mnemonic
> > >>>>> 
> > >>>>> http://bioconductor.org/limma
> > >>>>> 
> > >>>>> To redirect to
> > >>>>> 
> > >>>>> 
> > >>>>> 
> > >>>> http://bioconductor.org/packages/limma/whateverTheMostRecentStableVersionMayBe/
> > >>>> 
> > >>>>> 
> > >>>>> And then everything is explicit.
> > >>>>> 
> > >>>>> Does that address the competing issues discussed herein?
> > >>>>> 
> > >>>> 
> > >>>> 
> > >>>> Note that 'release' and 'devel' are just symlinks to the
> > >>>> current
> > >>>> release
> > >>>> and devel versions. I.e. currently 3.0 and 3.1 respectively.
> > >>>> So
> > >>>> you can
> > >>>> always link directly to a specific version.
> > >>>> 
> > >>>> Dan
> > >>>> 
> > >>>> 
> > >>>>> Best,
> > >>>>> 
> > >>>>> --t
> > >>>>> _______________________________________________
> > >>>>> Bioc-devel at r-project.org mailing list
> > >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > >>>>> 
> > >>>> 
> > >>>> 
> > >>>> 
> > >>> [[alternative HTML version deleted]]
> > >>> 
> > >>> _______________________________________________
> > >>> 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
> > >> 
> > >> 
> > > 
> > > --
> > > 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
> > > 
> > 
> > [[alternative HTML version deleted]]
> > 
> > _______________________________________________
> > Bioc-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> > 
> 
>

More information about the Bioc-devel mailing list