In point of fact, it looks like IRanges 2.6.0 is an instance of that weakness, so was probably a bad example. 2.6.1 installs correctly, or would in it's native R/base bioc environment... (it fails for me in the library I have...)
Also, the version on CRAN uses the bioc SVN, so may not work for recent versions. On Thu, Oct 5, 2017 at 3:58 PM, Gabe Becker <becke...@gene.com> wrote: > Henrik et al., > > My switchr package (on CRAN, github at: http://github.com/gmbecker/switchr, > preprint of the paper here: https://arxiv.org/abs/1501.02284 > <https://arxiv.org/abs/1501.02284>) can do this. > > In fact, installing (cohorts of) old versions of packages is one of it's > primary purposes. Specifically, it can install old source versions of > packages from CRAN, Bioconductor, and general Git and SVN repos you tell it > about. > > With the caveat that it's a bad idea in the general case to specify an old > version of one package without specifying versions of its dependencies > (switchr allows you to do this via a manifest, which can be constructed > from sessionInfo output or guessed in the case of a CRAN package), you can > just do > > > man = PkgManifest(name="IRanges", type="bioc") > > > install_packages("IRanges", man, versions = c(IRanges = "2.6.0")) > > > And you will successfully completely break your Bioc installation by > installing IRanges 2.6.0 into it. ;-) > > Switchr also gives you tools to more easilly maintain multiple libraries > which contain, for example, different bioc versions in them. > > NB: switchr is subject to the caveat Martin pointed out and will fail to > retrieve a buildable version of the package if said buildable version is > not the first commit in SCM bearing that version in its DESCRIPTION file. > > Hope that helps. > > Best, > ~G > > On Thu, Oct 5, 2017 at 2:21 PM, Martin Morgan < > martin.mor...@roswellpark.org> wrote: > >> On 10/05/2017 05:14 PM, Henrik Bengtsson wrote: >> >>> On Thu, Oct 5, 2017 at 1:46 PM, Martin Morgan >>> <martin.mor...@roswellpark.org> wrote: >>> >>>> On 10/05/2017 01:50 PM, Henrik Bengtsson wrote: >>>> >>>>> >>>>> Is there an easily accessible archive for Bioconductor packages >>>>> similar to what is provided on CRAN where you can find all released >>>>> versions of a package, e.g. >>>>> https://cran.r-project.org/src/contrib/Archive/PSCBS/? >>>>> >>>>> Say I want to access the source code for affy 1.18.0. Here are the >>>>> two approaches I'm aware of and none of them are particularly >>>>> appealing to me. Does anyone know of a better approach? >>>>> >>>> >>>> >>>> The only option is to scrape, and that's approximate. One could build an >>>> archive >>>> >>>> pkg,version,branch,from_svn_rev,to_svn_rev >>>> >>>> and then consult that. Packages are supposed to increment the 'z' of >>>> x.y.z, >>>> but I'm sure there are many exceptions. I believe Jim Hester has an svn >>>> script for this, but I wasn't able to locate it; it would be fast in >>>> git. >>>> >>> >>> Thanks. About 'z' not being increased. Does the Bioc build servers >>> release (a) continuously or (b) only when it detects a version change >>> x.y.z -> x.y.z+1? If it does it continuously, then what x.y.z is >>> installed does matter on when it was downloaded/installed, correct? >>> On the other hand, if it only builds in when a version bump is >>> detected, then one can at least narrow it down to a much narrow set of >>> x.y.z submits (if multiple exists). >>> >> >> The builder only pushes for upward increments, so a commit without a >> 'positive' version bump would be built but not pushed to the public >> repository. I'm not sure how rigorously this policy was enforced before, >> e.g., 2005. >> >> Of course there are exceptions, e.g., it is occasionally (at most one or >> two times a release cycle) necessary to flush the public repository >> entirely, and then whatever is built is pushed. And there is nothing >> stopping the user from doing a check-out from svn. Perhaps others will >> chime in with the gory / correct details. >> >> Martin >> >> >> >>> >>>> For your future self, this >>>> >>>> https://bioconductor.org/packages/3.5/bioc/src/contrib/Arch >>>> ive/S4Vectors/ >>>> >>>> provides a hint of a change coming with the next release -- archives of >>>> all >>>> RELEASE package versions, starting in Bioc 3.6. (Kudos to Val for >>>> implementing this) >>>> >>> >>> This is great! Thanks Val for this. >>> >>> Thanks >>> >>> Henrik >>> >>> >>>> Martin >>>> >>>> >>>>> >>>>> # APPROACH 1: Download from http://bioconductor.org >>>>> >>>>> The best approach I know now is to try to guess the date when this was >>>>> released in order to identify the Bioconductor release version. >>>>> Something like this: >>>>> >>>>> 1. Guess around 2010. >>>>> >>>>> 2. Go to http://bioconductor.org/about/release-announcements/ and see >>>>> what R versions were in use during 2010. I find R 2.6.x and R 2.7.x. >>>>> The Bioc version for those R versions (same URL) are Bioc 2.1 and Bioc >>>>> 2.2. Let's focus on Bioc 2.2 (because I happen to know that is the >>>>> one) >>>>> >>>>> 3. Following the Bioc 2.2 link on above URL to get to >>>>> http://bioconductor.org/packages/2.2/BiocViews.html. >>>>> >>>>> 4. Click through, one eventually gets to >>>>> http://bioconductor.org/packages/2.2/bioc/html/affy.html >>>>> >>>>> 5. The "Source" link points to >>>>> http://bioconductor.org/packages/2.2/bioc/src/contrib/affy_1 >>>>> .18.2.tar.gz >>>>> >>>>> Say I wanted affy 1.16.0 instead and I made the wrong guess in Step 2, >>>>> I can extrapolate from (Bioc 2.2, affy 1.18.x) finding that I should >>>>> go to Bioc 2.1 to find affy 1.16.x (because releases have even minor >>>>> version numbers). It works, but is a bit tedious if you need to do >>>>> this more than once. >>>>> >>>>> Also, I'm pretty sure I read somewhere that Bioc on archive the most >>>>> recent package version under each release, which means there is no >>>>> affy_1.18.0.tar.gz available for download. Is that correct? >>>>> >>>>> >>>>> # APPROACH 2: Version control >>>>> >>>>> $ git clone https://git.bioconductor.org/packages/affy >>>>> $ cd affy >>>>> >>>>> # Package releases/versions are not tagged >>>>> $ git tag >>>>> [empty] >>>>> >>>>> # Check Bioc release branches >>>>> $ git branch -a >>>>> * master >>>>> remotes/origin/HEAD -> origin/master >>>>> remotes/origin/RELEASE_1_0 >>>>> remotes/origin/RELEASE_1_0_branch >>>>> remotes/origin/RELEASE_1_4 >>>>> remotes/origin/RELEASE_1_4_branch >>>>> remotes/origin/RELEASE_1_5 >>>>> [...] >>>>> remotes/origin/RELEASE_3_5 >>>>> remotes/origin/master >>>>> >>>>> That's back to above game of trying to narrow down which Bioc release >>>>> I should look at. A similar approach is to look at the commit log: >>>>> >>>>> $ git log DESCRIPTION >>>>> >>>>> commit 35573048255b398f99ff1d3560906b2121912248 >>>>> Author: Herve Pages <hpa...@fhcrc.org> >>>>> Date: Mon Apr 24 19:50:57 2017 +0000 >>>>> >>>>> bump x.y.z versions to odd y after creation of 3_5 branch >>>>> >>>>> git-svn-id: >>>>> >>>>> file:///home/git/hedgehog.fhcrc.org/bioconductor/trunk/madma >>>>> n/Rpacks/affy@129129 >>>>> bc3139a8-67e5-0310-9ffc-ced21a209358 >>>>> >>>>> commit aa4c2d648658e8c2cca2baf651aea92df55a4392 >>>>> Author: Herve Pages <hpa...@fhcrc.org> >>>>> Date: Mon Apr 24 19:25:24 2017 +0000 >>>>> >>>>> bump x.y.z versions to even y prior to creation of 3_5 branch >>>>> >>>>> git-svn-id: >>>>> >>>>> file:///home/git/hedgehog.fhcrc.org/bioconductor/trunk/madma >>>>> n/Rpacks/affy@129126 >>>>> bc3139a8-67e5-0310-9ffc-ced21a209358 >>>>> >>>>> [...] >>>>> >>>>> and try to locate affy 1.18.0 by peeking at the DESCRIPTION file >>>>> history. >>>>> >>>>> Does anyone know of a better/more automated approach? >>>>> >>>>> Thanks, >>>>> >>>>> Henrik >>>>> >>>>> _______________________________________________ >>>>> Bioc-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >>>>> >>>>> >>>> >>>> This email message may contain legally privileged and/or confidential >>>> information. If you are not the intended recipient(s), or the employee >>>> or >>>> agent responsible for the delivery of this message to the intended >>>> recipient(s), you are hereby notified that any disclosure, copying, >>>> distribution, or use of this email message is prohibited. If you have >>>> received this message in error, please notify the sender immediately by >>>> e-mail and delete this email message from your computer. Thank you. >>>> >>> >> >> This email message may contain legally privileged and/or...{{dropped:2}} >> >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > > > -- > Gabriel Becker, Ph.D > Associate Scientist > Bioinformatics and Computational Biology > Genentech Research > -- Gabriel Becker, Ph.D Associate Scientist Bioinformatics and Computational Biology Genentech Research [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
