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 <mtmor...@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.g...@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 <jspid...@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@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>>> >>> >>> >>> >>> -- >>> Computational Biologist >>> Genentech Research >>> >>> [[alternative HTML version deleted]] >>> >>> _______________________________________________ >>> Bioc-devel@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.ri...@berkeley.edu _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
