[MRG] Add support for installing different versions of R

[betatim]

Closes #661

This uses the instructions from https://cran.r-project.org/bin/linux/ubuntu/README.html to allow users to select a different version of R. We use the runtime.txt to let users specify which version they want via r-3.6-YYYY-MM-DD (selects R 3.6, 3.6.1 to be precise) or r-YYYY-MM-DD (selects the default, currently 3.4).

We can also add support for R 3.5 but I wanted to open the PR before being done. Ideally r-3.4-YYYY-MM-DD should be equivalent to r-YYYY-MM-DD as well.

This is pretty exciting as it adds a frequently requested feature without a lot of new code.

What do people think of using runtime.txt like this? I like it and prefer it over trying to guess a R version from the date or introducing an additional file. Maybe in a second PR we can check if a DESCRIPTION file can specify a R version as well.

It would be good to get some feedback from R packaging experts on https://cran.r-project.org/bin/linux/ubuntu/README.html.

• R 3.5 support
• make 3.6 the default
• tests
• docs

[trallard]

Thanks for working on this @betatim

Some thoughts here:

• It would make more sense to have the latest R version as the "empty one". So that the most recent version of R would be installed by default. This will make it consistent with the Rocker Docker images behaviour (which is what I would expect for example from the Jupyter notebooks stack as well)
• I quite like the idea of having the R version explicitly declared in the runtime.txt as r-3.6-YYYY-MM-DD this reduces a lot of ambiguity and makes the R version used/requested highly visible
• I vote in favour of directly supporting 3.5 - I believe a good chunk of R users will either be running on 3.5 or 3.6 (probably more than 3.4) as this is quite old now

[betatim]

It would make more sense to have the latest R version as the "empty one"

I was wondering about that. Right now I went with "nothing should change when we merge this", currently you can't select the R version so after merging this PR if you don't specify anything we stick (unfortunately) with what used to be the only version. This is the "never break users" mantra. I don't actually know how many existing repos would break if we suddenly switch them from 3.4 to 3.6. Is there a way to guess-timate that (without having to go and build a whole bunch of repos)?

For Python we didn't follow this mantra and at some point switched to Python 3.7 as the default. There were a few (but less than expected) people who had problems with their repos not building any more who showed up on twitter/gitter/the forum. What is unknown is how many repos kept building but now produced different results (probably less than those that broke).

I need to check what we do for Julia (no spec -> we update your version or no spec -> we stick to some old version).

[trallard]

This would be particularly hard to guesstimate, but I do not expect a huge number of repos to break if we upgrade to 3.6 right away.
That said I imagine there will be a few (maybe more than a few) repos currently broken as some R packages tend to drop support for old R base versions. Of course there are workarounds to install packages for an older R version.

Something that could be done would be upgrading to 3.6 (as in Python) and perhaps add a FAQ/detailed documentation on the repo2docker and binder pages so that this does not result in loads of issues around the line "my repo worked a week ago and now it's broken"?

[NHDaly]

When I first made the change in Julia, I kept everyone on the old version. But the Julia transition from 0.6 (the default before) to 1.0 was more significant -- 0.6 is no longer supported, and almost no one uses it, so we then changed the default to 1.0. Now, I don't think we've been updating the version to run the latest Julia, which probably makes sense. 1.0 is the "long-term supported" version, so I think continuing to update the default to the latest patch release of 1.0 is reasonable (1.0.4, 1.0.5, etc). I'm not sure how much of that maps to the situation for R? For the full details on Julia's version numbers, they just released this thorough blog post that discusses the above in more detail: https://julialang.org/blog/2019/08/release-process Hopefully that's helpful! :) Sorry if it was too much information.

…

On Wed, Sep 4, 2019, 3:57 AM Tim Head ***@***.***> wrote: It would make more sense to have the latest R version as the "empty one" I was wondering about that. Right now I went with "nothing should change when we merge this", currently you can't select the R version so after merging this PR if you don't specify anything we stick (unfortunately) with what used to be the only version. This is the "never break users" mantra. I don't actually know how many existing repos would break if we suddenly switch them from 3.4 to 3.6. Is there a way to guess-timate that (without having to go and build a whole bunch of repos)? For Python we didn't follow this mantra and at some point switched to Python 3.7 as the default. There were a few (but less than expected) people who had problems with their repos not building any more who showed up on twitter/gitter/the forum. What is unknown is how many repos kept building but now produced different results (probably less than those that broke). I need to check what we do for Julia (no spec -> we update your version or no spec -> we stick to some old version). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#772>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMCIEKDG3O7LWTZWAF6GIDQH5S4ZANCNFSM4ITCDFSA> .

[NHDaly]

Now, I don't think we've been updating the version to run the latest Julia,
which probably makes sense. 1.0 is the "long-term supported" version, so I
think continuing to update the default to the latest patch release of 1.0
is reasonable (1.0.4, 1.0.5, etc).

Oh, just kidding, apparently we just use the latest released version of julia as the default:
https://github.com/jupyter/repo2docker/blob/46cd5670e821f210930562a42e2769488bd23149/repo2docker/buildpacks/julia/julia_project.py#L30
🤷‍♂i think that's reasonable too. :) Supposedly, the upgrades are always supposed to be backwards compatible within 1.*, even if downgrades aren't. So this is probably fine as well.

Anyway, hope that's helpful. :)

[choldgraf]

This seems pretty reasonable to me - it feels like a good piggy-backing of the runtime buildpack. Just to have 👀 on it, one other pattern we could use is something like:

r-VERSION
mran-YYYY-MM-DD

which would be more explicit (although two separate lines) and would disentangle the two pieces of information. I can see "pros" and "cons" with both approaches, but curious what other folks think about this

[betatim]

This is ready for review now @minrk or @nuest

[nuest]

Just have a couple of questions, otherwise the code looks 💯

[nuest]

Exactly, the latest R version in the 3 series. It would move along similar to a x.y version. You are right, it probably makes more sense to do it when there are alternatives (like support for 2.x.z or >3. Maybe R stays with 3 for a long time!).

[nuest]

LGTM

[betatim]

I updated the documentation to mention R version support. Ready to merge if the bots are happy.

[betatim]

Now with more LooseVersion @minrk

[betatim]

Merging this now. Min's last (in person) comment on this was positive except for the part about not using LooseVersion which is now fixed.