Re: [Bioc-devel] Short URLs for packages?
Awesome, thank you! Now how about forwarding this: http://bioconductor.org/packages/ to this: http://bioconductor.org/packages/release/BiocViews.html#___Software ... I guess that's what bookmarks are for, but ... who uses those anymore, anyway? :-) On Tue, Apr 28, 2015 at 11:08 AM, Dan Tenenbaum dtene...@fredhutch.org wrote: - Original Message - From: Wolfgang Huber whu...@embl.de To: bioc-devel@r-project.org Sent: Monday, March 23, 2015 3:17:03 AM Subject: [Bioc-devel] Short URLs for packages? I wonder whether it'd possible to have the website understand URLs like http://www.bioconductor.org/pkgname This could resolve to http://www.bioconductor.org/packages/release/bioc/html/pkgname.html or http://www.bioconductor.org/packages/devel/bioc/html/pkgname.html depending on whether the package was yet released. This could be handy in papers or grants that mention packages. We came up with something close to this, but it does include the /packages/ segment because we think that's important. http://bioconductor.org/packages/BiocGenerics/ - takes you to the release landing page, unless the package is only in devel, in which case it takes you to the devel landing page (which will contain suitable warnings/instructions about installing the devel version). You can also specify 'devel' or 'release' or a numbered Bioconductor version: http://bioconductor.org/packages/devel/BiocGenerics/ http://bioconductor.org/packages/release/BiocGenerics/ http://bioconductor.org/packages/3.2/BiocGenerics/ http://bioconductor.org/packages/3.1/BiocGenerics/ http://bioconductor.org/packages/3.0/BiocGenerics/ ... (The trailing slashes are optional in all of these). These are redirects and not forwards; that is, if you enter one of these short URLs, it won't remain in your browser's address bar but will change to one of the longer URLs. So they are sort of ephemeral in this way. We looked into doing these as forwards (i.e., short URL remains in address bar, but content from 'long' URL is served), which seems more useful, but there were too many problems with that; it breaks relative URLs and more importantly it breaks our mirrors which do not necessarily have the same content root as our web site. At any rate, the short URLs can be used in publications and other sites, and they are useful as a permanent link to the current release version of a package. We have added information about these short URLs to the emails we send to new package developers, so that they can use them in publications that reference their packages. Thanks, Dan Wolfgang Wolfgang Huber Principal Investigator, EMBL Senior Scientist Genome Biology Unit European Molecular Biology Laboratory (EMBL) Heidelberg, Germany T +49-6221-3878823 wolfgang.hu...@embl.de http://www.huber.embl.de ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Steve Lianoglou Computational Biologist Genentech ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Short URLs for packages?
- Original Message - From: Steve Lianoglou lianoglou.st...@gene.com To: Dan Tenenbaum dtene...@fredhutch.org Cc: Wolfgang Huber whu...@embl.de, bioc-devel@r-project.org Sent: Tuesday, April 28, 2015 3:57:25 PM Subject: Re: [Bioc-devel] Short URLs for packages? Awesome, thank you! Now how about forwarding this: http://bioconductor.org/packages/ to this: http://bioconductor.org/packages/release/BiocViews.html#___Software Done. Dan ... I guess that's what bookmarks are for, but ... who uses those anymore, anyway? :-) On Tue, Apr 28, 2015 at 11:08 AM, Dan Tenenbaum dtene...@fredhutch.org wrote: - Original Message - From: Wolfgang Huber whu...@embl.de To: bioc-devel@r-project.org Sent: Monday, March 23, 2015 3:17:03 AM Subject: [Bioc-devel] Short URLs for packages? I wonder whether it'd possible to have the website understand URLs like http://www.bioconductor.org/pkgname This could resolve to http://www.bioconductor.org/packages/release/bioc/html/pkgname.html or http://www.bioconductor.org/packages/devel/bioc/html/pkgname.html depending on whether the package was yet released. This could be handy in papers or grants that mention packages. We came up with something close to this, but it does include the /packages/ segment because we think that's important. http://bioconductor.org/packages/BiocGenerics/ - takes you to the release landing page, unless the package is only in devel, in which case it takes you to the devel landing page (which will contain suitable warnings/instructions about installing the devel version). You can also specify 'devel' or 'release' or a numbered Bioconductor version: http://bioconductor.org/packages/devel/BiocGenerics/ http://bioconductor.org/packages/release/BiocGenerics/ http://bioconductor.org/packages/3.2/BiocGenerics/ http://bioconductor.org/packages/3.1/BiocGenerics/ http://bioconductor.org/packages/3.0/BiocGenerics/ ... (The trailing slashes are optional in all of these). These are redirects and not forwards; that is, if you enter one of these short URLs, it won't remain in your browser's address bar but will change to one of the longer URLs. So they are sort of ephemeral in this way. We looked into doing these as forwards (i.e., short URL remains in address bar, but content from 'long' URL is served), which seems more useful, but there were too many problems with that; it breaks relative URLs and more importantly it breaks our mirrors which do not necessarily have the same content root as our web site. At any rate, the short URLs can be used in publications and other sites, and they are useful as a permanent link to the current release version of a package. We have added information about these short URLs to the emails we send to new package developers, so that they can use them in publications that reference their packages. Thanks, Dan Wolfgang Wolfgang Huber Principal Investigator, EMBL Senior Scientist Genome Biology Unit European Molecular Biology Laboratory (EMBL) Heidelberg, Germany T +49-6221-3878823 wolfgang.hu...@embl.de http://www.huber.embl.de ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Steve Lianoglou Computational Biologist Genentech ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] building R and bioconductor
Hi all, Laurent: Thanks for the shout-out! It's gratifying to see that people have noticed what I'm doing. Berri, As Laurent suggested, my switchr package (currently at http://github.com/gmbecker/switchr , on CRAN soon) is designed to do this. It has a few features which I think are relevant to what you're asking for: - It is designed to easily install cohorts of packages - or specific versions thereof. - It uses install.packages to get dependency issues right, while adding an extra layer that understands versions, and can retreive old versions from a variety of sources (github, CRAN Archive, Bioc previous releases and SVN, etc). - It provides a mechanism for describing cohorts of specific package versions (a SeedingManifest) in a form that can be - used to install the listed packages - deployed as a traditional repository (including integration testing) via my related GRANBase package - Published or distributed in a light-weight manner, e.g. as a github gist (via http://github.com/gmbecker/switchrGist ) I would argue that whatever approach you choose should deal with package dependencies and installation order automatically. There should be no reason for you to need to specify those yourself, and lots of downsides of doing so. AFAIK RStudio's packrat and my switchr systems both have this property. Some things switchr doesn't do: - Anything at the R-version level or above. - This is ripe for a combination with a docker-based approach. Carl Boettiger (cc'ed) is one of the people behind https://github.com/rocker-org/rocker and there was some discussion of incorporating switchr there for this purpose, but I don't know if anything has happened with that yet. - Binary packages - Currently, you must have the ability to build all the packages you want from source on the destination system. I'm happy to answer any further questions about switchr or to hear about features you need that it doesn't seem to have yet. Best, ~G On Tue, Apr 28, 2015 at 10:36 AM, Laurent Gatto lg...@cam.ac.uk wrote: Dear Stefano, On 28 April 2015 16:50, Berri, Stefano wrote: Hi. I need a very reproducible way of creating a R builds with a series of CRAN and Bioconductor packages. I want to be able to download a specific version or R, a specific version of all packages and then install them in the right order (to make sure every package has the dependencies at installation time). I do not want to use install.packages or biocLite because they are not very transparent/reproducible I have done it for R-3.0.2, but it has been rather slow and boring (Try installing a package, see the complaint, go into a working installation, load the package an figure out the version of all the related packages). I am wondering if there is an automated way, or a repository, to recursively retrieve all the package versions required in a certain version of R. Using biocLite, you will get the specific package versions required for your R version. If you want more control, I think packrat [1,2] from RStudio or this paper [3] by Gabe Becker et al. might helpful. [1] https://rstudio.github.io/packrat/ [2] https://github.com/rstudio/packrat [3] http://arxiv.org/abs/1501.02284 You might also consider rolling out your own docker image. [4] http://bioconductor.org/help/docker/ I am also looking into easybuild (http://easybuild.readthedocs.org/en/latest/), and, also there, knowing the exact path to all the packages in the right order seem crucial. how do install.packages or biocLite know what version is required and where it is located? The locations are defined by getOption(repos) and biocinstallRepos() respectively. In the latter case, these will also depend on the version of R. Hope this helps. Best wishes, Laurent Thanks a lot Stefano ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Gabriel Becker, Ph.D Computational Biologist Genentech Research [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] building R and bioconductor
Dear Stefano, On 28 April 2015 16:50, Berri, Stefano wrote: Hi. I need a very reproducible way of creating a R builds with a series of CRAN and Bioconductor packages. I want to be able to download a specific version or R, a specific version of all packages and then install them in the right order (to make sure every package has the dependencies at installation time). I do not want to use install.packages or biocLite because they are not very transparent/reproducible I have done it for R-3.0.2, but it has been rather slow and boring (Try installing a package, see the complaint, go into a working installation, load the package an figure out the version of all the related packages). I am wondering if there is an automated way, or a repository, to recursively retrieve all the package versions required in a certain version of R. Using biocLite, you will get the specific package versions required for your R version. If you want more control, I think packrat [1,2] from RStudio or this paper [3] by Gabe Becker et al. might helpful. [1] https://rstudio.github.io/packrat/ [2] https://github.com/rstudio/packrat [3] http://arxiv.org/abs/1501.02284 You might also consider rolling out your own docker image. [4] http://bioconductor.org/help/docker/ I am also looking into easybuild (http://easybuild.readthedocs.org/en/latest/), and, also there, knowing the exact path to all the packages in the right order seem crucial. how do install.packages or biocLite know what version is required and where it is located? The locations are defined by getOption(repos) and biocinstallRepos() respectively. In the latter case, these will also depend on the version of R. Hope this helps. Best wishes, Laurent Thanks a lot Stefano ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] building R and bioconductor
Martin, On Tue, Apr 28, 2015 at 10:52 AM, Martin Morgan mtmor...@fredhutch.org wrote: Downloading a specific version of Bioconductor packages retrospectively is challenging, unless the version is the final version in a release cycle. This is because the Bioc repository only contains one version of a package for each release, and while it is might be possible to dissect the svn logs of individual packages to identify when a DESCRIPTION file had a particular version, there may be several svn commits associated with the version (packages are only pushed to the public repository when a version changes at the time the build starts each day, so the first svn revision would be a good [but not infallible] bet as to the revision that was made public). This is true. switchr does this via the heuristic that you suggest. The model here is that a version bump (in SVN/github/etc) represents a new version of the package, and that all changes between version bumps simply accumulate but do not arrive until the next version of the pacakge. If you wish to take a snapshot 'now' and have it available in the future, then the tools Laurent mentions might be appropriate. I think I would rather (but maybe I'm just perverse in this respect) rsync ( http://bioconductor.org/about/mirrors/mirror-how-to/ and similar for CRAN) or manually create a 'CRAN-style' repository of source packages, and simply use this as the 'repos' argument (including pointing to a local file system) in install.packages. Again, switchr does this via a concept called lazy repositories, which are built on demand with only the required packages, but that is how dependencies between packages are supported, even when those packages don't currently reside in any repository. Best, ~G -- Gabriel Becker, Ph.D Computational Biologist Genentech Research [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Biobase: Imports repeats Depends
On Mon, Apr 27, 2015 at 6:45 PM, Hervé Pagès hpa...@fredhutch.org wrote: Hi Henrik, I know it's not necessary and I know that the WRE manual and 'R CMD check' don't like this but I like to list in Imports what I import and to list in Depends what I want to see attached to the search() path. For the same reason that I like to explicitly export the generic functions that I define in my packages even if exporting the methods defined on these generics is enough (because it has the side effect to automatically export the generic). More generally it's about expressing intentions directly versus expressing them in an indirect manner (e.g. by relying on side effects). I think the latter is wrong. Hope that makes sense. Thanks for clarifying. I simply thought it was a mistake/cut'n'paste typo. H.. Cheers, H. On 04/25/2015 01:12 PM, Henrik Bengtsson wrote: It seems unnecessary that BiocGenerics have the same package under Imports as under Depends. The former can be dropped. packageDescription(BiocGenerics) Package: BiocGenerics Title: S4 generic functions for Bioconductor Description: S4 generic functions needed by many Bioconductor packages. Version: 0.14.0 Author: The Bioconductor Dev Team Maintainer: Bioconductor Package Maintainer maintai...@bioconductor.org biocViews: Infrastructure Depends: methods, utils, graphics, stats, parallel Imports: methods, utils, graphics, stats, parallel Suggests: Biobase, S4Vectors, IRanges, GenomicRanges, AnnotationDbi, oligoClasses, oligo, affyPLM, flowClust, affy, DESeq2, MSnbase, annotate, RUnit License: Artistic-2.0 Collate: S3-classes-as-S4-classes.R normarg-utils.R update-utils.R . NeedsCompilation: no Packaged: 2015-04-17 03:42:27 UTC; biocbuild Built: R 3.3.0; ; 2015-04-25 20:08:25 UTC; windows /Henrik ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Bioc package pages: List also BugReports for a package?
Beautiful. Thxs Henrik On Mon, Apr 27, 2015 at 6:47 PM, Dan Tenenbaum dtene...@fredhutch.org wrote: - Original Message - From: Henrik Bengtsson henrik.bengts...@ucsf.edu To: bioC-devel bioc-de...@stat.math.ethz.ch Sent: Sunday, April 26, 2015 7:14:20 PM Subject: [Bioc-devel] Bioc package pages: List also BugReports for a package? For affxparser, we've got the following in DESCRIPTION: URL: https://github.com/HenrikBengtsson/affxparser BugReports: https://github.com/HenrikBengtsson/affxparser/issues But t's only the URL field that is listed on the package page(s): http://www.bioconductor.org/packages/release/bioc/html/affxparser.html http://www.bioconductor.org/packages/devel/bioc/html/affxparser.html May I suggest to also have BugReports listed on package pages? Done (only added if the package DESCRIPTION contains a BugReports field). Dan Thanks, Henrik ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
