[feature request] Add the ability to build xeus-cpp in a container

[mcbarton]

I will begin work soon to add the ability to build xeus-cpp inside a container. This issue is more to detail my initial plan

• Add a python script which can used to build xeus-cpp for all platforms (linux, macos, windows and emscripten)
• Add a minimal docker file which simply calls the python script with the correct options, exposing the port needed so that xeus-cpp can be experienced in a browser outside the container
• Add a minimal apptainer file which simply calls the python script with the correct options, exposing the port needed so that xeus-cpp can be experienced in a browser outside the container (apptainer is to cover the use of xeus-cpp on hpc systems where docker is not available due to security issues)
• Update the docker and apptainer files to expose a users gpu to the container (if the user has one) once the cuda kernels are available

Steps for after this work is done

• Build the docker images locally, and get them uploaded docker hub, so users in future can just download the docker image, and run it locally to experience xeus-cpp

[JohanMabille]

I like the idea of providing containers so that user can easily experience xeus-cpp, but I think this should be done in a dedicated repo instead of here (just like the feedstock for conda-forge is not part of this repo for instance). Besides, I don't understand the need for a Python script to build a native repo; why not using plain CMake and cmake presets instead? Are there limitations?

[SylvainCorlay]

I was also going to ask what is the benefit of invoking a Python script from the command line over invoking cmake from the command line?

[mcbarton]

@SylvainCorlay @JohanMabille The idea behind the python script is that it can be used as a one line command to build either the jupyter lab or jupyter lite site inside the containers (docker and apptainer to cover most situations) in order to reduce duplication. If you look at the draft python script (despite being draft the python script works if you want to try it out) I have so far in #410

To build the native version of xeus-cpp and run jupyter lab with the kernel installed you execute

python scripts/xeus-cpp-build.py --build native --launch-lab

To build the Emscripten version of xeus-cpp and run jupyter lite with the kernel installed you execute (this will also run the browser tests)

python scripts/xeus-cpp-build.py --build emscripten --run-browser-tests --launch-lite

The idea is that the build command in the containers will omit the --launch-lab and --launch-lite commands. The command when you run the containers will have these flags, and expose the port needed. Having the python script as part of the repo would allow a user who wants to build locally a single command to execute to experience xeus-cpp on their platforms, rather than having to go back and forth from the readme to their terminal to build if they choose too (to be clear the cmake instructions would stay and not be removed).

You should also not just think about the containers as useful from a user perspective. Having the containers as part of the repo can give xeus-cpp contributors a minimal replicatable clean environment which they can build inside of.

@vgvassilev @alexander-penev can correct me if I am wrong, but with xeus-clang-repl the container file being inside the repo also allowed for the binder link in the readme to build the latest version of xeus-clang-repl on main for developers to inspect (I should be able to make binder PR previews of the current status of the jupyter lab build just like the jupyter lite PR previews xeus-cpp has).

[JohanMabille]

You should also not just think about the containers as useful from a user perspective. Having the containers as part of the repo can give xeus-cpp contributors a minimal replicatable clean environment which they can build inside of.

II definitely agree on the utility of these containers, for both users and developers. My point was that they should live in a dedicated repo, for the sake of separation of concerns. Otherwise we could also add micromamba (or a script to download and install it) to this repo because it is also a way to get a clean environment with all the dependencies required to build xeus-cpp. And then we can say the same for any tool providing the same feature.