Re: [Bioc-devel] 2 candidates for BiocGenerics
Hi,
The organism and species accessors (getters and setters) are now generic
functions in BiocGenerics (>= 0.13.8).
To my knowledge all the packages in devel (except rsbml) that define
(or use) these accessors were modified to use these new generics.
Please let me know if I forgot some.
Some clarifications (just added now in BiocGenerics 0.13.9) in the
man page for these generics:
Value:
‘organism’ should return the _scientific name_ (i.e. genus and
species, or genus and species and subspecies) of the organism.
Preferably in the format ‘"Genus species"’ (e.g. ‘"Homo sapiens"’)
or ‘"Genus species subspecies"’ (e.g. ‘"Homo sapiens
neanderthalensis"’).
‘species’ should of course return the species of the organism.
Unfortunately there is a long history of misuse of this accessor
in Bioconductor so its usage is now discouraged (starting with
BioC 3.1).
Note:
TO DEVELOPPERS:
‘species’ has been historically misused in many places in
Bioconductor and is redundant with ‘organism’. So implementing the
‘species’ accessor is now discouraged (starting with BioC 3.1).
The ‘organism’ accessor (returning the _scientific name_) should
be implemented instead.
Cheers,
H.
On 03/10/2015 07:28 AM, Laurent Gatto wrote:
Dear all,
Two possible candidates for BiocGenerics:
GenomeInfoDb::species
standardGeneric for "species" defined from package "GenomeInfoDb"
function (x)
standardGeneric("species")
Methods may be defined for arguments: x
Use showMethods("species") for currently available ones.
AnnotationDbi::species
standardGeneric for "species" defined from package "AnnotationDbi"
function (x)
standardGeneric("species")
Methods may be defined for arguments: x
Use showMethods("species") for currently available ones.
and
annotate::organism
standardGeneric for "organism" defined from package "annotate"
function (object)
standardGeneric("organism")
Methods may be defined for arguments: object
Use showMethods("organism") for currently available ones.
GenomeInfoDb::organism
standardGeneric for "organism" defined from package "GenomeInfoDb"
function (x)
standardGeneric("organism")
Methods may be defined for arguments: x
Use showMethods("organism") for currently available ones.
Best wishes,
Laurent
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Short URLs for packages?
I just think there are a couple of subtleties here. I certainly don't begrudge people wanting to type less and find packages easier. But if a naive user with a default (read: release) Bioc installation goes to http://bioconductor.org/CoolAwesomePkg and see's that it is "available in bioconductor" but then can't install it because it is only in devel, are they going to be less confused, or more? I don't know the answer to that, but I think it's something to consider. We have (and already had many times) exactly this problem. A paper is published and refers to a new BioC-package. The naive user is not able to find the package. We want to show the naive user that this package is indeed part of bioconductor and point him/her to a way to install the package. The devel-webpage makes a clear statement on top saying “This is the development version of BiocGenerics; for the stable release version, see MyPackage.” If this is not prominent enough, one can highlight this with yellow color. Also, as I have said elsewhere, though I acknowledge that you seem to disagree, I think such urls are substantially less appropriate for credit/citation in publications. A link that brought users to the version in question, but which - if not current - had a prominent link to the current version would be better imho. This discussion is off-topic. The versioning system of Bioconductor provides a sufficient way to cite the right version of the packages to ensure reproducible research. We (try to) do this in the papers as well. We do not request that short URLs should replace the correct citation of package versions. Here, we ask for a stable, short URL that links to the most current, stable version of the package (which is in devel for the time between acceptance and first release of the package). Most users reading about a bioconductor package want to install the current version of the package, that is best tested,with the lowest number of bugs, installable on a current machine, with a current version of R, … . We want to put a stable URL into a paper, that does not need to be changed anymore, when the BioC-package moves from devel to release. There is no way to change the paper after publication. Bernd ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Short URLs for packages?
There are still problems with completely reproducing old analyses partly due to our (current) inability to reproduce an exact version (as Martin says). But I don't think we should muddle the waters and mix URL schemas with versioning. What Wolfgang is asking for is something I think makes total sense and which I support: the ability to refer to a single url and get the "latest" version of a package. The url I usually give out is ../release/PACKAGE.html but that does not work for a package which has not yet been part of a release. Depending on your manuscript / package development process I could easily see a manuscript getting accepted for publication around the same time the package gets accepted into Bioc. It has happened to me. And like Wolfgang, I don't like to have ../devel/PACKAGE.html links in my papers. To me, this seems like a very slight extension to the ../release/PACKAGE.html schema, and I don't really understand the reluctance to have this. I am also happy to start a discussion on how to refer to specific versions of a package including what we might need to support in Bioconductor to achieve better reproducibility - which is what I think Gabe refers to - but I don't think we should confuse this (important) issue with the schema request. Best, Kasper On Tue, Mar 24, 2015 at 11:15 AM, Gabe Becker wrote: > On Tue, Mar 24, 2015 at 7:28 AM, Wolfgang Huber wrote: > > > > 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. > > > > But we already have dynamic resolution. Even > > http://bioconductor.org/release/BiocGenerics will point to different > > package versions (e.g. after bugfixes) as time goes by. > > So the attribute “release” is dynamically resolved. > > All I am asking for is another attribute that means “the best that we > > currently have”, i.e. release if it exists and devel otherwise. > > > > I didn’t expect so much disagreement on so mundane an issue. And there > are > > plenty of ways of doing this outside the Bioc webpage, any of the public > > ’tiny URL’ services, through my own webpage, or by just telling people to > > google the package name. > > > > I just think there are a couple of subtleties here. I certainly don't > begrudge people wanting to type less and find packages easier. But if a > naive user with a default (read: release) Bioc installation goes to > http://bioconductor.org/CoolAwesomePkg and see's that it is "available in > bioconductor" but then can't install it because it is only in devel, are > they going to be less confused, or more? I don't know the answer to that, > but I think it's something to consider. > > Also, as I have said elsewhere, though I acknowledge that you seem to > disagree, I think such urls are substantially less appropriate for > credit/citation in publications. A link that brought users to the version > in question, but which - if not current - had a prominent link to the > current version would be better imho. > > > > > > > > On 24 Mar 2015, at 12:14, Martin Morgan > wrote: > > > > > > 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/…. > > > > I don’t agree. This would mean that for each later version of the same > > package, even just after a trivial typo fix, there is either no article, > or > > another one would have to be written. I don’t think this has an easily > > formalized solution, some good judgement is required. > > E.g. try to apply the above reasoning to > > > http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1003118 > > > I agree that there can be a bit of a "beard problem*" here. If people > follow the Bioc development guidelines, though, I think a pretty good rule > of thumb can be had: bugfix version changes (in the major.minor-bugfix > nomenclature) are (relatively unambiguously) the "same" software from a > publication standpoint, while package versions with minor or major version > differences are not. This doesn't mean that a new article need to be > written, imo, just that awareness that the article discussed a different > version of the software - and that users should see the NEWS file or > current documentation for fully up-to-date information - is important. > > Not to harp on you personally, Wolfgang, because your paper with Simon > about DESeq was ahead of its time (and ours, sadly) on many of these > issues, but the API and default behavior of DESeq have changed > substantially (and for the better!) since its publication [1]. > > As a never-going-to-happen pipedream, this would be even
Re: [Bioc-devel] Short URLs for packages?
On Tue, Mar 24, 2015 at 7:28 AM, Wolfgang Huber wrote: > > 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. > > But we already have dynamic resolution. Even > http://bioconductor.org/release/BiocGenerics will point to different > package versions (e.g. after bugfixes) as time goes by. > So the attribute “release” is dynamically resolved. > All I am asking for is another attribute that means “the best that we > currently have”, i.e. release if it exists and devel otherwise. > > I didn’t expect so much disagreement on so mundane an issue. And there are > plenty of ways of doing this outside the Bioc webpage, any of the public > ’tiny URL’ services, through my own webpage, or by just telling people to > google the package name. > I just think there are a couple of subtleties here. I certainly don't begrudge people wanting to type less and find packages easier. But if a naive user with a default (read: release) Bioc installation goes to http://bioconductor.org/CoolAwesomePkg and see's that it is "available in bioconductor" but then can't install it because it is only in devel, are they going to be less confused, or more? I don't know the answer to that, but I think it's something to consider. Also, as I have said elsewhere, though I acknowledge that you seem to disagree, I think such urls are substantially less appropriate for credit/citation in publications. A link that brought users to the version in question, but which - if not current - had a prominent link to the current version would be better imho. > > > On 24 Mar 2015, at 12:14, Martin Morgan wrote: > > > > 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/…. > > I don’t agree. This would mean that for each later version of the same > package, even just after a trivial typo fix, there is either no article, or > another one would have to be written. I don’t think this has an easily > formalized solution, some good judgement is required. > E.g. try to apply the above reasoning to > http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1003118 I agree that there can be a bit of a "beard problem*" here. If people follow the Bioc development guidelines, though, I think a pretty good rule of thumb can be had: bugfix version changes (in the major.minor-bugfix nomenclature) are (relatively unambiguously) the "same" software from a publication standpoint, while package versions with minor or major version differences are not. This doesn't mean that a new article need to be written, imo, just that awareness that the article discussed a different version of the software - and that users should see the NEWS file or current documentation for fully up-to-date information - is important. Not to harp on you personally, Wolfgang, because your paper with Simon about DESeq was ahead of its time (and ours, sadly) on many of these issues, but the API and default behavior of DESeq have changed substantially (and for the better!) since its publication [1]. As a never-going-to-happen pipedream, this would be even more straight-forward if Bioc package version numbers were of the form (BiocVersion.PkgVersion-bugfix). Then the automatic incrementing of package versions for bioc releases wouldn't muddy the waters here. * The philosophical issue where some men obviously have beards, and some men obviously don't, but there is no exact number of facial hairs at which one unambiguously transitions from not having a beard to having one. [1] http://blog.revolutionanalytics.com/2014/08/gran-and-switchr-cant-send-you-back-in-time-but-they-can-send-r-sort-of.html ~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
Re: [Bioc-devel] Rtools warning on tracker page
The builder for submitted packages uses the devtools package and this is a bug in devtools: https://github.com/hadley/devtools/issues/717 You can ignore it. Dan - Original Message - > From: "Glyn Bradley" > To: bioc-devel@r-project.org > Sent: Tuesday, March 24, 2015 3:03:36 AM > Subject: [Bioc-devel] Rtools warning on tracker page > > Hi > After uploading our package to the tracker, it built successfully on > all systems with no errors. > But we have the following Rtools related WARNING: > > WARNING: Rtools is required to build R packages, but no version of > Rtools > compatible with R 3.2.0 was found. (Only the following incompatible > version(s) > of Rtools were found:2.13,2.14,2.15,2.16) > > > > Is it possible this is related to the build environment on the > tracker page? > > We can't think how it could be related to our package. > > I have already mailed the BioC team about this, but I thought I'd > post it here also to see if anyone else has the same issue. > (our package is called 'CausalR'). > > Best Regards, > Glyn > > > > > > This e-mail was sent by GlaxoSmithKline Services Unlimited > (registered in England and Wales No. 1047315), which is a > member of the GlaxoSmithKline group of companies. The > registered address of GlaxoSmithKline Services Unlimited > is 980 Great West Road, Brentford, Middlesex TW8 9GS. > > [[alternative HTML version deleted]] > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Short URLs for packages?
> 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. But we already have dynamic resolution. Even http://bioconductor.org/release/BiocGenerics will point to different package versions (e.g. after bugfixes) as time goes by. So the attribute “release” is dynamically resolved. All I am asking for is another attribute that means “the best that we currently have”, i.e. release if it exists and devel otherwise. I didn’t expect so much disagreement on so mundane an issue. And there are plenty of ways of doing this outside the Bioc webpage, any of the public ’tiny URL’ services, through my own webpage, or by just telling people to google the package name. > On 24 Mar 2015, at 12:14, Martin Morgan wrote: > > 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/…. I don’t agree. This would mean that for each later version of the same package, even just after a trivial typo fix, there is either no article, or another one would have to be written. I don’t think this has an easily formalized solution, some good judgement is required. E.g. try to apply the above reasoning to http://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1003118 Wolfgang ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Short URLs for packages?
#5 is what I was thinking of when I responded. A simple RewriteRule, if anyone
still uses Apache.
"Release" vs "devel" and/or "3.0" vs "3.1" vs "3.2", e.g.
> http://bioconductor.org/release/BiocGenerics/
Pointing analogously to
> http://bioconductor.org/3.0/BiocGenerics/
seems like a good minimal standard (project + version + package)
--t
> On Mar 24, 2015, at 4:14 AM, Martin Morgan 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
Re: [Bioc-devel] Short URLs for packages?
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. 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
[Bioc-devel] Rtools warning on tracker page
Hi After uploading our package to the tracker, it built successfully on all systems with no errors. But we have the following Rtools related WARNING: WARNING: Rtools is required to build R packages, but no version of Rtools compatible with R 3.2.0 was found. (Only the following incompatible version(s) of Rtools were found:2.13,2.14,2.15,2.16) Is it possible this is related to the build environment on the tracker page? We can't think how it could be related to our package. I have already mailed the BioC team about this, but I thought I'd post it here also to see if anyone else has the same issue. (our package is called 'CausalR'). Best Regards, Glyn This e-mail was sent by GlaxoSmithKline Services Unlimited (registered in England and Wales No. 1047315), which is a member of the GlaxoSmithKline group of companies. The registered address of GlaxoSmithKline Services Unlimited is 980 Great West Road, Brentford, Middlesex TW8 9GS. [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Short URLs for packages?
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.
Wolfgang
> On Mar 23, 2015, at 18:43 GMT+1, Tim Triche, Jr. 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
>
> On Mon, Mar 23, 2015 at 9:29 AM, Dan Tenenbaum
> wrote:
>
>>
>>
>> On March 23, 2015 9:18:57 AM PDT, "Tim Triche, Jr."
>> 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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
