Containers for older versions of R about rocker

[eddelbuettel]

Sure.

But I think it is out of scope for the rocker project.

[eddelbuettel]

(Technical reason: One repo, one commit, one trigger of rebuilds at hub.docker.com)

It would be pretty straightforward to take our 'build from source' recipe for r-devel, fetch a given versioned tarball of R from CRAN abd build it. Ditto with packages from the CRAN Archive section satisfying the date constraint.

You may also want to look into the (totally awesome and under-recognised) Debian Snapshot Archive as it already has dated / versioned .deb binaries for you.

So it sounds like a nice new 'nice to have' initiative but I fear I don;t have bandwidth for it. [ Unless we all commit to get at least one example run written, documented and written'ed up for hands-on publication. ]

[cboettig]

@hadley definitely sounds interesting...

@eddelbuettel Now that we have a https://github.com/rocker-org, it's less
important to stick with the single repo model. In particular, creating
additional repos under http://github.com/rocker-org that still use the
http://hub.docker.com/repos/rocker namespace on DockerHub might be a good
way to organize around potential extensions like this, particularly if
someone like @hadley wanted to take the lead in building out that new
repo. What do you think?

On Fri, Oct 10, 2014 at 7:17 AM, Dirk Eddelbuettel <[email protected]

wrote:

(Technical reason: One repo, one commit, one trigger of rebuilds at
hub.docker.com)

It would be pretty straightforward to take our 'build from source' recipe
for r-devel, fetch a given versioned tarball of R from CRAN abd build it.
Ditto with packages from the CRAN Archive section satisfying the date
constraint.

You may also want to look into the (totally awesome and under-recognised) Debian
Snapshot Archive http://snapshot.debian.org/ as it already has dated /
versioned .deb binaries for you.

So it sounds like a nice new 'nice to have' initiative but I fear I don;t
have bandwidth for it. [ Unless we all commit to get at least one example
run written, documented and written'ed up for hands-on publication. ]

—
Reply to this email directly or view it on GitHub
#29 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[eddelbuettel]

We are definitely open to other volunteers willing to run with this; I just wanted to sound you out as well in terms of whether you and I consider to be part of the current rocker scope.

I do not think so, hence I'd close this. Thoughts?

[hadley]

I'd be happy to help out to the extent that I'm able. Maybe create rocker-old/rchive or similar?

[eddelbuettel]

rocker-versioned/r-base-x.y.z for suitable values of x,y,z ?

[hadley]

Seems reasonable. Probably a question is whether we want r-base-x.y.z or just r-base-x.y which would just track the latest minor version.

[eddelbuettel]

One useability-limiting factor is that you can not just say 'run the r-2.13.0 image and install the matching foo package` as we AFAIK lack the ability to infer what matching version of foo we want. Right or wrong?

[hadley]

Where foo is an R package? It might be possible to build something either using https://github.com/metacran/crandb or by looking at which versions of the package have windows binaries for the corresponding R version.

[cboettig]

Haven't used it, but loading the old package versions on earlier builds of
R sounds like it's along the lines of @gmbecker 's gRAN and switchr
packages do? see
http://blog.revolutionanalytics.com/2014/08/gran-and-switchr-cant-send-you-back-in-time-but-they-can-send-r-sort-of.html
though Gabe could probably comment or correct me.

On Fri, Oct 10, 2014 at 10:13 AM, Hadley Wickham [email protected]
wrote:

Where foo is an R package? It might be possible to build something either
using https://github.com/metacran/crandb or by looking at which versions
of the package have windows binaries for the corresponding R version.

—
Reply to this email directly or view it on GitHub
#29 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[eddelbuettel]

Regarding:

• r-base-x.y.z we may as well print the z that was last and use the 'final such version' -- but the idea is good to just use the last revision per major.minor.* suite
• yes, 'foo` was meant to designate a CRAN package name; sorry for omitting all the underscores and 2s you're used too ;-)
• and yes, there may be some code floating around but we have to make it available here or else we set users up for the nasty ones of 'current version of foo does not build on ancient R' detracting from the whole idea

[gmbecker]

@cboettig,

Thanks for thinking of me.

Indeed, I have a package (GRANBase, name possibly to be changed, paper
being written) which will get you old versions of package from CRAN or
Bioconductor (currently) or arbitrary SCM (experimental/forthcoming). The
software is functional but a bit rough right now but is in the process of
being polished during the paper-writing process.

In fact, in preparation for the blog post you linked, I did something quite
analagous to what I believe you are talking about, creating an AMI with R
2.12 and then populating it with old package versions listed in a published
sessionInfo using GRANBase+switchr.

GRANBase + switchr do a lot of things related to the same ideas you guys
are exploring, but the bits most relevant here are locatePkgVersion and
getPkgVersions.

We also have the concept of lazy/JIT repositorories, so it would be
sufficient to have a list of of the package versions you wish to define as
a cohort, whether it is a previous state of the entire CRAN ecosystem
(e.g., CRAN for R 2.x.x) or something narrower. Looks like the crandb
software @hadley mentions gives us that (and a lot more, cool project!)

Happy to chat about this stuff more.
~G

On Fri, Oct 10, 2014 at 10:24 AM, Dirk Eddelbuettel <
[email protected]> wrote:

Re

• r-base-x.y.z we may as well print the z that was last and use the
  'final such version' -- but the idea is good.
• yes, 'foo` was meant to designate a CRAN package name; sorry
  omitting all the underscores and 2s you're used too ;-)
• and yes, there may be some code floating around but we have to make
  it available here or else we set users up for the nasty ones of 'current
  version of foo does not build on ancient R' detracting from the whole idea

—
Reply to this email directly or view it on GitHub
#29 (comment).

Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

[cboettig]

@gmbecker thanks for chiming in here. Yeah, it sounded like your efforts
would be rather complementary: your approach pre-supposes the right version
of R (e.g. via the amazon AMI image), which is something it sounds like we
can can accomplish in a straight-forward manner on Docker as
@eddelbuettel's suggests, while it looks like you've figured out how to get
the right package for that version. Can you give us a quick example of what
that looks like? e.g. is there the equivalent of an install.packages
function in GRANbase that I could run on some very old version of R and
know that it would build correctly?

On Fri, Oct 10, 2014 at 11:00 AM, Gabe Becker [email protected]
wrote:

@cboetig,

Thanks for thinking of me.

Indeed, I have a package (GRANBase, name possibly to be changed, paper
being written) which will get you old versions of package from CRAN or
Bioconductor (currently) or arbitrary SCM (experimental/forthcoming). The
software is functional but a bit rough right now but is in the process of
being polished during the paper-writing process.

In fact, in preparation for the blog post you linked, I did something
quite
analagous to what I believe you are talking about, creating an AMI with R
2.12 and then populating it with old package versions listed in a
published
sessionInfo using GRANBase+switchr.

GRANBase + switchr do a lot of things related to the same ideas you guys
are exploring, but the bits most relevant here are locatePkgVersion and
getPkgVersions.

We also have the concept of lazy/JIT repositorories, so it would be
sufficient to have a list of of the package versions you wish to define as
a cohort, whether it is a previous state of the entire CRAN ecosystem
(e.g., CRAN for R 2.x.x) or something narrower. Looks like the crandb
software @hadley mentions gives us that (and a lot more, cool project!)

Happy to chat about this stuff more.
~G

On Fri, Oct 10, 2014 at 10:24 AM, Dirk Eddelbuettel <
[email protected]> wrote:

Re

• r-base-x.y.z we may as well print the z that was last and use the
  'final such version' -- but the idea is good.
• yes, 'foo` was meant to designate a CRAN package name; sorry
  omitting all the underscores and 2s you're used too ;-)
• and yes, there may be some code floating around but we have to make
  it available here or else we set users up for the nasty ones of 'current
  version of foo does not build on ancient R' detracting from the whole
  idea

—
Reply to this email directly or view it on GitHub
#29 (comment).

Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

—
Reply to this email directly or view it on GitHub
#29 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[cboettig]

@hadley @gmbecker I've created
https://github.com/rocker-org/rocker-versioned and invited you both to the
repo.

On Fri, Oct 10, 2014 at 11:28 AM, Carl Boettiger [email protected] wrote:

@gmbecker thanks for chiming in here. Yeah, it sounded like your efforts
would be rather complementary: your approach pre-supposes the right version
of R (e.g. via the amazon AMI image), which is something it sounds like we
can can accomplish in a straight-forward manner on Docker as
@eddelbuettel's suggests, while it looks like you've figured out how to get
the right package for that version. Can you give us a quick example of what
that looks like? e.g. is there the equivalent of an install.packages
function in GRANbase that I could run on some very old version of R and
know that it would build correctly?

On Fri, Oct 10, 2014 at 11:00 AM, Gabe Becker [email protected]
wrote:

@cboetig,

Thanks for thinking of me.

Indeed, I have a package (GRANBase, name possibly to be changed, paper
being written) which will get you old versions of package from CRAN or
Bioconductor (currently) or arbitrary SCM (experimental/forthcoming). The
software is functional but a bit rough right now but is in the process of
being polished during the paper-writing process.

In fact, in preparation for the blog post you linked, I did something
quite
analagous to what I believe you are talking about, creating an AMI with R
2.12 and then populating it with old package versions listed in a
published
sessionInfo using GRANBase+switchr.

GRANBase + switchr do a lot of things related to the same ideas you guys
are exploring, but the bits most relevant here are locatePkgVersion and
getPkgVersions.

We also have the concept of lazy/JIT repositorories, so it would be
sufficient to have a list of of the package versions you wish to define
as
a cohort, whether it is a previous state of the entire CRAN ecosystem
(e.g., CRAN for R 2.x.x) or something narrower. Looks like the crandb
software @hadley mentions gives us that (and a lot more, cool project!)

Happy to chat about this stuff more.
~G

On Fri, Oct 10, 2014 at 10:24 AM, Dirk Eddelbuettel <
[email protected]> wrote:

Re

• r-base-x.y.z we may as well print the z that was last and use the
  'final such version' -- but the idea is good.
• yes, 'foo` was meant to designate a CRAN package name; sorry
  omitting all the underscores and 2s you're used too ;-)
• and yes, there may be some code floating around but we have to make
  it available here or else we set users up for the nasty ones of
  'current
  version of foo does not build on ancient R' detracting from the whole
  idea

—
Reply to this email directly or view it on GitHub
#29 (comment).

Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis

—
Reply to this email directly or view it on GitHub
#29 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[cboettig]

I was able to get R 2.0.0 to compile from svn as Dirk suggested, but not R 1.0. I also took a look at installing the binaries from the debian snapshots, but this requires a bit more tweaking to grab dependencies. Anyway, I've added examples of both approaches to the new repository; feel free to modify or delete them as you see fit. You could probably knock out a lot of versions pretty quickly by merely adjusting the svn tags. Since development has moved to that repo I'll close this issue here.

[shabbychef]

Would it be possible to manually tag rocker/r-base just before an update of the R version occurs? By 'manually', I mean go to the 'build settings' tab in docker hub, and triggering a build with the corresponding Docker tag name.

[eddelbuettel]

If I hear "manual" I don't want yet another job to take care of / have to remember. What we have now is not all that bad:

edd@max:~$ docker images r-base
REPOSITORY          TAG             IMAGE ID            CREATED             VIRTUAL SIZE
r-base              3.2.3           7939bc63acf9        13 days ago         1.071 GB
r-base              latest          7939bc63acf9        13 days ago         1.071 GB
r-base              3.2.2           d8d772db8b82        11 weeks ago        998.9 MB
r-base              3.2.1           38a6a6b62751        6 months ago        563.5 MB
r-base              3.2.0           c09b226d89bc        6 months ago        551.6 MB
r-base              3.1.3           8a0dd612a7f5        9 months ago        516.7 MB
r-base              3.1.2           c04052b3ddd2        10 months ago       483.5 MB
edd@max:~$ 

Good enough?

[ And yes, some of those where off. I think 3.1.2 and 3.1.3 both are 3.1.3 etc pp. But preservation of old versions is not really the stated goal of this project, irrespective of how many times people nudge us that way. We do have some related projects. ]

[shabbychef]

I think this might, thanks @eddelbuettel . (One of my packages apparently does not CRAN-check on R 3.1, and I am trying to hunt this down, so I need access to an 'old' version of R, preferrably via docker.) Given the mapping from tag to image ID, I think I can access these images from docker-hub by using the FROM image@digest syntax which was introduced in Docker 1.6. I will write this up if/when I get it working. thanks again,

[eddelbuettel]

I'd add Depends: R (>= 3.2.0).

(and I am only half in jest...)

[gmbecker]

Steven,

If you have issues installing/managing appropriately old versions of your
package's dependencies, my switchr package (
https://github.com/gmbecker/switchr) is designed to help with that. See
specifically ?rVersionManifest to get a manifest of appropriate tarballs
for use in install_packages.

Please feel free to drop me a line if you have any questions or it doesn't
seem to meet your needs in some way (or doesn't work).

On Mon, Jan 11, 2016 at 10:02 AM, Steven Pav [email protected]
wrote:

I think this might, thanks @eddelbuettel https://github.com/eddelbuettel
. (One of my packages apparently does not CRAN-check on R 3.1, and I am
trying to hunt this down, so I need access to an 'old' version of R,
preferrably via docker.) Given the mapping from tag to image ID, I think I
can access these images from docker-hub by using the FROM image@digest
syntax which was introduced in Docker 1.6. I will write this up if/when I
get it working. thanks again,

—
Reply to this email directly or view it on GitHub
#29 (comment).

Gabriel Becker, PhD
Associate Scientist (Bioinformatics)
Genentech Research

[shabbychef]

I think @eddelbuettel's half jest solution wins him a cigar, at least for now.