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

Martin Morgan mtmorgan at fhcrc.org
Wed Sep 10 20:19:08 CEST 2014


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



More information about the Bioc-devel mailing list