[Bioc-devel] biocLite message "R package not available" is confusing

davide risso risso.davide at gmail.com
Wed Sep 10 23:00:28 CEST 2014


Hi Martin,

> I wonder where the users are getting the notion that they _should_ be able
> to install RUVSeq in Bioc 2.14? I guess they follow the link in the Nature
> Methods paper to the devel landing page, then follow the 'Installation'
> instructions without paying attention to the various 'development version'
> flags on the page.

Yes. I also think they follow the link and just copy/paste the
biocLite() command without reading the rest of the page.

Best,
davide


On Wed, Sep 10, 2014 at 12:21 PM, Martin Morgan <mtmorgan at fhcrc.org> wrote:
> On 09/10/2014 11:37 AM, davide risso wrote:
>>
>> Thanks Martin,
>>
>> yes, you're right about the "use the devel version," but perhaps
>> biocLite could check if the package is available in the devel, just to
>> distinguish between a package that is not in Bioconductor (mistyping?)
>> and one that is not yet available in release.
>
>
> biocLite() already scores high on the tangled code scale.
>
> The problem is that this month's 'devel' will actually be next month's
> 'release' and next year's 'previous version', so it's very hard to know
> where to look for the available version, and how to reliably tell the user
> what to do to get the package.
>
> If it's a simple typo of an available package then install.packages will
> already suggest an alternative.
>
> I wonder where the users are getting the notion that they _should_ be able
> to install RUVSeq in Bioc 2.14? I guess they follow the link in the Nature
> Methods paper to the devel landing page, then follow the 'Installation'
> instructions without paying attention to the various 'development version'
> flags on the page.
>
> Martin
>
>
>>
>> Just my two cents.
>>
>> Davide
>>
>> On Wed, Sep 10, 2014 at 11:19 AM, Martin Morgan <mtmorgan at fhcrc.org>
>> wrote:
>>>
>>> On 09/10/2014 10:39 AM, davide risso wrote:
>>>>
>>>>
>>>> I just wanted to add my support to Josef request.
>>>>
>>>> During the last few weeks I received several emails from users asking
>>>> me if I "plan to make a version of RUVSeq compatible with R 3.1." (My
>>>> RUVSeq package is in devel).
>>>>
>>>> I understand the error comes directly from install.packages, but is
>>>> there a way for biocLite to catch this before passing it to
>>>> install.packages? Perhaps throwing a different error, like "The
>>>> package xxx is not available in the release version of Bioconductor.
>>>> Use the devel version."
>>>>
>>>> The current error message is not just confusing, it's incorrect.
>>>
>>>
>>>
>>> I don't think we'd say 'use the devel version' but we could say something
>>> about 'not available for this version of Bioconductor'; I'll also think
>>> about getting this 'fixed' upstream (it's not the version of R, but the
>>> repositories specified in the call to install.packages)
>>>
>>> Martin
>>>
>>>
>>>>
>>>> Best,
>>>> davide
>>>>
>>>> On Tue, Aug 19, 2014 at 4:57 PM, Gabe Becker <becker.gabe at gene.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Josef,
>>>>>
>>>>> The problems with reviewers you are describing sound very frustrating
>>>>> (for
>>>>> the author and the reviewer) but I suspect you think that biocLite is
>>>>> doing
>>>>> somethign that it is not (reimplementing the actual package
>>>>> installation
>>>>> machinery in R). Responses inline.
>>>>>
>>>>>
>>>>> On Tue, Aug 19, 2014 at 4:40 PM, Josef Spidlen <jspidlen at bccrc.ca>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I believe that the "R package ... is not available for R ..." message
>>>>>> as
>>>>>> produced by biocLite is a bit confusing for "new-ish" BioConductor
>>>>>> users,
>>>>>> and I have a suggestion how things could be improved.
>>>>>>
>>>>>> Imagine that a brand new package is submitted to BioConductor and a
>>>>>> related
>>>>>> manuscript to some journal. Your typical reviewer as well as most
>>>>>> other
>>>>>> users that heard about the package will search for it and end up
>>>>>> somewhere
>>>>>> under http://bioconductor.org/packages/devel/bioc/..... From there,
>>>>>> they
>>>>>> will simply copy&paste
>>>>>> source("http://bioconductor.org/biocLite.R")
>>>>>> biocLite("myFancyPackage")
>>>>>> into their R 3.1 console, which will tell them that the package is not
>>>>>> available for their version of R despite the fact that the actual
>>>>>> package
>>>>>> "depends" on, say, R >= 2.10.0.
>>>>>>
>>>>>
>>>>> This message is from install.packages, which biocLite calls, not
>>>>> biocLite
>>>>> itself. The message is the generic "the repository you pointed at
>>>>> doesn't
>>>>> have a version of the package you wanted installable on your system"
>>>>> (types
>>>>> of packages not withstanding).
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Your typical user may try several versions of R and than either give
>>>>>> up,
>>>>>> or
>>>>>> contact the maintainer. Your manuscript reviewer will reject the
>>>>>> manuscript
>>>>>> as the "package is not available". Trust me, I have seen both happen,
>>>>>> and I
>>>>>> have answered several questions explaining how a package that is still
>>>>>> just
>>>>>> "a development version" can be installed.
>>>>>>
>>>>>> In order to make things less confusing, I would suggest that future
>>>>>> versions of biocLite check also the development section of
>>>>>> BioConductor
>>>>>> (if
>>>>>> a package cannot be found in the current release), and possibly
>>>>>> produce
>>>>>> a
>>>>>> message that is more informative, e.g.,
>>>>>> "R package ... is still in development; you can either try again after
>>>>>> the
>>>>>> next BioConductor release in October|April 20xx, or you can follow
>>>>>> these
>>>>>> steps to install the development version now: ..."
>>>>>>
>>>>>
>>>>> You can't (safely) mix package versions from Bioc-devel and
>>>>> Bioc-release,
>>>>> so the instructions there would be "use bioc devel". I could easily be
>>>>> put
>>>>> in the availability section of a paper "it will be available as a devel
>>>>> package until X/Y/ZZZZ, after which it will be a fully released bioc
>>>>> package"
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> And (less important), if biocLite "knew" which packages are from CRAN
>>>>>> rather than BioConductor (cache the names of the ~6,000 CRAN
>>>>>> packages?),
>>>>>> then it could also produce errors like "R package ... seems like a
>>>>>> CRAN
>>>>>> package; you may want to try install.packages to install it"). That
>>>>>> may
>>>>>> help some users as well.
>>>>>>
>>>>>
>>>>> biocLite does/can know where the packages come from, but again, it is
>>>>> just
>>>>> calling install.packages, and will happily install CRAN packages for
>>>>> you
>>>>> without any trouble.
>>>>>
>>>>> ~G
>>>>>
>>>>>
>>>>>>
>>>>>> That's just my 2c :-).
>>>>>>
>>>>>> Cheers,
>>>>>> Josef
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Josef Spidlen, Ph.D.
>>>>>> Staff Scientist, Terry Fox Laboratory, BC Cancer Agency
>>>>>> 675 West 10th Avenue, Vancouver, BC, V5Z1L3, Canada
>>>>>> Tel. +1 604-675-8000, ex. 7755
>>>>>>
>>>>>>           [[alternative HTML version deleted]]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Bioc-devel at r-project.org mailing list
>>>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Computational Biologist
>>>>> Genentech Research
>>>>>
>>>>>           [[alternative HTML version deleted]]
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>>
>>
>
>
> --
> 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



-- 
Davide Risso, PhD
Post Doctoral Scholar
Department of Statistics
University of California, Berkeley
344 Li Ka Shing Center, #3370
Berkeley, CA 94720-3370
E-mail: davide.risso at berkeley.edu



More information about the Bioc-devel mailing list