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

Wed Sep 10 20:37:57 CEST 2014

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.

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

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