[Bioc-devel] Short URLs for packages?

Vincent Carey stvjc at channing.harvard.edu
Tue Jul 7 22:12:26 CEST 2015 

OK, thanks.  Should we add a little bit to each package landing page
indicating how to link?

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
> >
>

	[[alternative HTML version deleted]]

More information about the Bioc-devel mailing list