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 <mtmor...@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 <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 >> >> >> >> > > > -- > 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
