Support different versions of R

[krlmlr]

By environment variable, so that this can also be done in a build matrix.

• [ ] By version number
• [ ] stable
• [ ] devel

[krlmlr]

By choice of ISO image (#13).

[krlmlr]

Need krlmlr/r-portable#4.

[jordansread]

:+1: this would be amazingly helpful if possible.

[krlmlr]

@jread-usgs: Much easier now since there's also R 3.2.0 on the image (https://github.com/krlmlr/r-portable/commit/2f27b665e0a619c95ef3fb8f14c3eb495fb3da32). Would you like to help with a pull request that enables choosing the version of R (e.g., via environment variable)?

[jordansread]

I think I can help, although I would probably need some back-and-forth. Is there a pattern elsewhere you would like to follow? r-builder or something else?

[krlmlr]

Currently the project is using the old travis-tool.sh. Good idea to move to r-builder, actually -- but I'm not sure what the effort is nor if it's possible to do in a backward-compatible way.

[gaborcsardi]

Also, r-builder is changing a lot more than travis-tool nowadays....

[krlmlr]

After re-reading the source, I think the two issues are orthogonal:

• Setting the PATH to R is done in appveyor-tool.ps1
• Downloading the travis-tool.sh is also done in appveyor-tool.ps1 but this does not affect the choice of the R version

This means that for choosing a different R version the code that sets PATH should be sensitive to some environment variable or even parameter. To me, an environment variable looks most practical, because this permits a build matrix for both R-stable and R-devel.

Now, there really seems to be no reason why pkg-build.sh should not be included in the r-portable image. If we do this, we can slowly phase out the usage of travis-tool.sh by recommending the new syntax in the devtools template. But again, I think this is a separate issue.

[jordansread]

@krlmlr how would you like to proceed given what you mention above?

[krlmlr]

@jread-usgs: I'd be happy to merge a pull request that allows an optional environment variable to set the PATH to R, which is now hard-coded.

[jordansread]

Thanks @krlmlr this looks doable, but I am just about to take a vacation for ~12 days. Hope it is ok to work on after I return.

[lawinslow]

This would be great. If a simple environment variable were supported, then you could use it in a build matrix to run multiple versions of R for each build.

[lawinslow]

@krlmlr Who is maintaining the R vhd file? Is this something you are manually creating and storing on Azure? I am trying to figure out where the vhd's of different versions would come from (to generate the correct URL).

[jordansread]

Aren't all the versions in one VHD file?

[lawinslow]

Not at the moment. Currently holds R-unstable and (EDIT) R-stable. Would support 2 and 3 above, but still need other versions by number.

[krlmlr]

See https://github.com/krlmlr/r-portable/issues/4 for the project and the issue that describes multiple R versions. @lawinslow: Did you mean r-unstable and r-stable?

[lawinslow]

Ha, yeah, that's what I meant.

[krlmlr]

If more than that is to be supported, probably the only way to go is to create individual images for different R versions -- R is not that small after all. For now it's those two versions of R.

[lawinslow]

Hmmm, my first thought here is to see if r-oldrel could be worked into this too. That way we'd always be able to cover the same range of R versions that CRAN supports (Any thoughts on this? I'd be happy to PR both r-portable and r-appveyor).

But one challenge there is that technically, one Rtools version wouldn't cover the full range. I'm not sure how much that matters though. Hmmmm.