TODO

Make envs available in jupytera

There's pixi-kernel but it is specifically "per directory", which does not fit our use case.

However, Pixi envs are compatible with nb_conda_kernels, which Leo installs on jupytera already.

The only "problem" is in how jupyter shows the env names:

prefix/envs/envname => prefix-envname

... which means that all pixi envs would show as .pixi-envname, which is weird. This can be solved by adding a symlink:

/sf/alvra/envs -> /sf/alvra/config/python/.pixi/envs

... so we'd get alvra-envname. As a bonus, the users may now add very intuitive paths to their .condarc.

Note: if the envs folder is called differently, no prefix is shown at all... This might be an alternative idea.

Shared features

Pixi supports "features" (i.e., sets of packages that allow the user to do XYZ). This would be very useful for, e.g., a feature like "be able to plot on jupytera", which gives the correct versions of ipympl, matplotlib, etc.

We would need this to be a central file that is somehow made available and/or merged into everyone's individual files.

Pixi does not seem to have this option (yet? opened a ticket). TOML does not allow to link in further files out of the box. However, there is tomlincl.

Running the setup script

Currently, there runs a deploy script as part of the deployment. We do NOT want to replace that script, but run after it.

Can this be changed such that the deploy script runs our script at the end? Where would our script live?

Timeout

Currently the timeout of the autodeployer is rather short as the expectation is that there are only "filesystem copy tasks" performed.

Conda env creation can take a few minutes even with Pixi.

Can the timeout be made that long without negative implications? Can this, for instance, block other tasks?

Trigger only on change of specific file

In case of changes to the env, the lock file (pixi.lock) should be committed at the end of the setup script to have a history and reproducibility.

Currently, this will trigger an additional autodeployer run which does nothing. This is a bit ugly.

Can we instead trigger the autodeployer only if pixi.yml changes?

Mounts

Problem

At creation time, conda envs hard code their location to several files.

From Simon:

The autodeployer runs in a podman container which maps:

/root/target (in container world)

to:

/net (in autodeployer machine host world)

Then, the autodeployer machine host has a diskmount that maps:

/net

to:

/gfa05

This means that references in the autodeployer config file such as the following:

gfa05/export/sf/alvra/config/python

result in writes to the combined path:

/net/gfa05/export/sf/alvra/config/python

Possible solution

Temporarily bind the autodeployer path to the console path:

sudo mkdir -p /sf/alvra/config/python
sudo mount --bind /root/target/gfa05/export/sf/alvra/config/python /sf/alvra/config/python
# install conda envs into /sf/alvra/config/python
sudo umount /sf/alvra/config/python
sudo rmdir -p /sf/alvra/config/python

3.2 KiB Raw Blame History