How to update package versions?

[Robinlovelace]

This is a question I asked in a different thread that got a great answer that answers it for a single user: rocker-org/geospatial#20 (comment)

I'm opening this as a separate issue here as I imagine it's an issue that many people face: you start using an image, you install some additional things on it and get some users, and then they ask why all the pkgs are out of date!

I found a solution to the that works for all users I believe. Why open an issue if it's solved? I think this could be better documented: I've had a good read and cannot find these instructions in any of the places I looked. In any case here's how I solved it (assuming this is a good way, let me know if not):

To 'unpin' packages so you get the latest versions of everything, across all users, you can do the following:

docker exec -it image_name /bin/bash
vim /usr/local/lib/R/etc/Rprofile.site
# comment out or change this line:
options(repos = c(CRAN='https://mran.microsoft.com/snapshot/2019-02-02'), download.file.method = 'libcurl')
# Save, restart R. Job done 

Happy it works on my tests, so wanting to share the knowledge.

[eddelbuettel]

Err, asking that is rocker-versioned is weird. Aren't those supposed to be frozen and versioned?

[Robinlovelace]

Yes. But what if a user happens to want to update the packages that they are using? Context: I'm using a docker image that builds FROM rocker/geospatial: https://github.com/Robinlovelace/geocompr/blob/master/Dockerfile

Would I be better building from a non-versioned version of rocker/geospatial? Please point me to the non versioned one if so (I imagine there's a tag that I missed).

[Robinlovelace]

Happy to ask this elsewhere. I think that the most frequently downloaded rocker images are versioned though, and that others will have that question. Hence asking, and tentatively answering, it here.

From your perspective it's probably more about documentation - only a few people know that the repos info is stored in /usr/local/lib/R/etc/Rprofile.site and it seems worth communicating that to the masses.

[Robinlovelace]

I think this would be the best place for such information: https://www.rocker-project.org/use/managing_containers/ Happy to put in a PR adding details on how packages are pinned.

[cboettig]

@Robinlovelace Thanks, yup that works, and documentation PR to the website would be great (sources here https://github.com/rocker-org/website) (it's just a hugo / blogdown site, so hopefully somewhat intuitive what to edit but ping me otherwise).

For some context, there's really two different workflows in mind here, and it might be helpful if we spelled those out more explicitly too. The way things are currently setup, the idea is basically to treat the container as a transient -- i.e. you do a fresh docker pull of, say, rocker/geospatial:latest, and it should be fully up-to-date. This is useful on cloud environments where you aren't likely to leave your instance up and running all the time, and you don't have to spend any $ of your cloud cycles merely compiling packages. Because it pins MRAN, if you then install additional packages, you get ones that were on CRAN at the same time everything else was built, and nothing is updated unless you explicitly set the repo, so it is more 'stable'.

But as you outline, this setup is not convenient for a less transient workflow, where you pull the image once, and then maybe customize it from there with new packages and new users, and want to keep updating software. In that scenario, ditching the MRAN pinning as you outline above often makes sense.

Thanks as always, your feedback and sharing are a big help to the community!

[Robinlovelace]

Hi @cboettig sorry it's been a while. Before suggesting any changes to docs, want to make sure I get it right. Do you know a better way of changing the default by updating the repos (3 times in on Rprofile.site I believe!)?:

https://github.com/Robinlovelace/geocompr/pull/428/files

Cheers

[cboettig]

Yeah, I think I have it in twice in the Rprofile.site by not dropping it elsewhere. Anyway, it's only the latest declaration that matters (it's just like any R code), so the way you link above will work fine. Also may be worth noting the standard hierarchy for .Rprofile works, so you can write to Rprofile.site to override for all users, or to ~/.Rprofile to override for the current user (i.e. /home/rstudio/.Rprofile, as root ~ is the root user!), or on a project by project basis with the local .Rprofile`. (Probably repeating what you know here but just to be complete).

[Robinlovelace]

See proposed fix. Suggest linking to an existing Dockerfile that builds on your images, e.g. https://github.com/Robinlovelace/geocompr/blob/master/Dockerfile

But wanted to keep changes in that commit to a minimum.

[eddelbuettel]

Dunno. That gets subjective quickly. We too derive from our own containers, this is very central to how Docker works. You could argue our own containers already do that. But whatevs.

(Minor nit: installGithub.r r-spatial/lwgeon is simpler that the R -e ... construct.)

[Robinlovelace]

Happy for major/rewrites of my suggested updated documentation. Sure some will find it useful. Good point re installGithub.r.

[eddelbuettel]

The PR is nice. I am unsure if / how this can be answered generically ... in a way that is not already covered by standard Docker documentation. As in "start with FROM, add RUN commands as you need them, ...".

[Robinlovelace]

Possibly the most useful part of the PR is a link to the rocker/r-ver Dockerfile, enabling people to see what you did, thereby making hacking what you did that much easier.