Rename base images

[joelostblom]

@ZacWarham What do you think of renaming the base images to -jupyterlab and -rstudio instead of -python and -r? Not the most urgent thing to do so hold off until you have more time, but in 531 I am exploring using jupyterlab for both python and R so the new naming would make more sense there.

[ZacWarham]

@joelostblom the reasoning at this point was because R and Python implied RStudio and Jupyterlab (and then postgres would imply pgadmin). I think switching to just -jupyterlab and -rstudio has the risk of having multiple -jupyterlab versions where one has just Python, one has R and one Postgres (or any combination).

I am happy for a change to be made that encompasses both, perhaps a course-ide-language naming convention? This may not be ideal for multi-language setups though so any thoughts would be appreciated.

I do have two concerns (that are definitely addressable) with making a change:

• The minor issue of bloating the MDS docker hub account with images
  • Could be a null point or just require Tiffany logging in and deleting old ones
• Some scripts in this repo and potentially in the migration repo have been written with the course-language naming convention in mind
  • Ultimately this just shows the trade-off I made favouring sanity checking user input as opposed to robustness of possible names and can be updated

Given your findings in #15 and the updates in https://github.com/PrairieLearn/PrairieLearn/pull/10713, it might be worth overhauling the current setup and instead of basing on the PL images (and working with their quirks), we switch to an IDE base and then have languages installed on top.

So instead of the current workflow being:

prairielearn/some-image -> mds/base -> mds/course

We treat languages as extensions instead of linked to an IDE:

mds/ide -> mds/language-a -> mds/language-b -> mds/course

[joelostblom]

I think switching to just -jupyterlab and -rstudio has the risk of having multiple -jupyterlab versions where one has just Python, one has R and one Postgres (or any combination).

I don't fully understand this. I'm thinking we will have a -jupyterlab base image and then each course will install the packages they want in that image which will be named something like -jupyterlab-531. If we get PL to maintain a jupyterlab-base image without python, then our base image could be minimal, maybe just the autosave tweak?

[ZacWarham]

My bad, I misread your original comment as referring to the course images as they are currently labelled ubcmds/531-r and thought you meant change these to ubcmds/531-jupyterlab

Then when I was explaining the second half of my response I was thinking of doing what you originally suggested without realising I misunderstood your suggestion 😅

To make sure we are on the same page then I would assume the workflow would be:

1. PL maintained minimal jupyter lab install
2. MDS maintained base image that enforces settings like autosave
3. MDS maintained course image that installs languages and packages

[joelostblom]

Perfect! That's what I have in mind too!

[ZacWarham]

On hold until PL has base implemented