Consider providing a toy example on how to enhance the base image

[larsvilhuber]

It's never super obvious (to me) how to expand on this at install time. Now that the container can simply use apt, an example on how to install a user's favorite packages at setup time (e.g., ggplot2) would be great. Maybe even using the "repo2docker" specs https://mybinder.readthedocs.io/en/latest/using/config_files.html#install-r-install-an-r-rstudio-environment

[larsvilhuber]

To be specific, this probably goes somewhere here: https://github.com/grantmcdermott/codespaces-r2u/blob/dee1a42e3607b7709af8a4979c2cbc1e605198bd/.devcontainer/devcontainer.json#L19

[eddelbuettel]

Have you seen what I did based on this repo over at r2u which is described in this blog post from two weeks ago?

[larsvilhuber]

I should probably be following that blog... but more seriously, it does not actually do the toy example of how to add those lines. I have found fiddling with postCreateCommand to be ... fiddly. It would be even more accessible to new users if you had a simple example. You can actually create Codespaces based on multiple configurations within the same .devcontainer (though again, I'm not super sure how), so you could have one configuration for a base container, one for a full tidyverse container, and you can choose at the time that you launch it.

One easy way to allow for this is to provide a standard script for postCreateCommand, like here and here, which might contains just apt install r-cran-tidyverse, say.

[eddelbuettel]

1. My examples were on purpose simple and added the install step in the .R file. With r2u even install.packages("tidyverse") is done in eighteen seconds or so (!!) as it a) gets binaries and b) benefits from bspm making this an apt installation step. And that was the point: to show how adding packages is easy in codespaces using r2u.

2. The real step to enhance a codespace is to enhance the underlying Docker container. How to do that is fairly common knowledge, reasonably well dcoumented in other places but maybe outside the scope of this repo.

3. I think I played locally with postCreateCommand and it seemed to work. If you have a concrete example I an sure we can cook something up. I'm traveling this week so it may have to wait a few days though.

[larsvilhuber]

Good points. I would argue though that having to manually do things every time you launch the codespace is not ideal (because see $$ and you don't want to have it just sitting there all the time). Doing it the r2u way is fine, as long as it would be done automatically after every build.

enhance the underlying Docker container. How to do that is fairly common knowledge

Define your audience... here, you are making R accessible easily in the cloud, WITHOUT the need to configure a Docker. It is by no means common knowledge in mainstream economics...

I'll create a pull request with a simple example.

[eddelbuettel]

I hear you, but recall that @grantmcdermott and I placed this in the context of r2u as a Rocker container. The basic Dockerfile can here be a two-liner with the FROM pointing to a container to start with (here: r2u) followed by a RUN command with a basic Rscript -e 'install.packages("tidyverse") (or ggplot2 or whatever). Of course then you'd probably want to push that container so that the codespace can use it.

In short: all do-able, needs some setup, needs a container repository account (Docker or GitHub's). But all that is fairly standard Docker practice and Docker has been around close to a decade now.

Or, if we want to keep it simple(r) with lower barriers to entry, we just run it in user space as my example scripts do. Both approaches work, and as always we may be trading off one feature for another.

[larsvilhuber]

See #9

[grantmcdermott]

Couple quick points:

1. Any packages that you install "manually" on a running devcontainer/codespaces instance will be available to you again when you reopen it. (I believe that it auto commits these additions to the container.) This is one reason why I really like this setup for teaching; once students install a package---a skill that they probably should be learning---it will be available to them in the next class, provided they just restart the same instance. And ofc the benefit of r2u in this instance is that we make installation very fast and failsafe when it does happen.

2. The dedicated way to install packages at build time is via the apt-packages feature, e.g. r-cran-ggplot2, r-cran-sf, etc. You do need to ensure the correct installation order, but I think that's pretty clearly documented. Given this, I'm not so keen to reinvent the wheel with an ad hoc approach to installing packages at build time. (Even if I think your proposal is quite elegant, Lars.)

I apologise if I missed something. I read through this thread very quickly, so please shout if you think I'm talking passed you.

[larsvilhuber]

@grantmcdermott Not sure about "auto commit". I don't think so.

If you (1) start a codespace (2) install packages (3) go back to whatever else you do (4) container sleeps (5) come back later, start the SAME container again - your packages are still there, because it is the same instance.

If (5) happens more than the auto-delete period later, then you are starting a NEW instance of the devcontainer, and then none of the manual installs are present.

The default retention period is 30 days. https://docs.github.com/en/codespaces/developing-in-codespaces/deleting-a-codespace. That consumes storage. The counter gets reset every time you use it.

I agree that students should learn how to install packages. But we also want to enable them to use it outside of the context of the class, in other circumstances.

I'm not arguing that the basic tutorial should show you how to do it. But it helps a lot (after having tried to teach this a few times, without the benefit of this great tutorial though) to have a really simple example that allows you to enhance this and make it your own.

My example used the install.R approach, because it would seem the most natural once the student has understood R (same commands). If you want to use apt-packages, then a similar approach would be to use apt.txt and write a simple wrapper around that. I think the install.R is more natural in this context, rather then the more sysadmin-y approach using apt (which is wonderfully hidden away from the user in the basic setup!).

I totally agree that building your own Docker image is the more powerful approach. I use it myself. Which is why I know that eyes glaze over when I explain it to others....