Creating and maintaining interactive environments

Rationale

In Spack, we often want to create environments that users will use interactively for a given purpose; it may contain multiple packages built from different sources. This is my recommended procedure for doing so, assuming that the built packages involved are already installed in your Spack instance, either by spack install or spack buildcache install, or are installed in an upstream repository.

Initial creation

These environments can be created initially by spack env create-ing an environment with a unique name, spack add-ing specific packages by build hash and doing a spack install, and finally symlinking to the environment a name for end users, something like "hypot_current_almalinux9" for the current hypot experiment environment for that OS.

spack env create unique_name_1
spack env activate unique_name_1
spack add package1/hash1
spack add package2/hash2
...
spack install
spack cd --env
cd ..
ln -s unique_name_1 hypot_current_almalinux9

Updating

As time goes on, one frequently wants to install updated versions of various packages in these environments for users to use. You can first replicate the environment, and modify the copy, test it, and then move where the symlink points.

To replicate the environment,

spack env activate unique_name_1
spack cd --env
spack env create unique_name_2 spack.lock
spack env activate unique_name_2 

Then to modify the environment:

spack env activate unique_name_2 
spack remove package/oldhash
spack add package/newhash
spack install

Now you can test that environment, and make sure it meets your needs, and finally

spack cd --env
cd ..
rm hypot_current_almalinux9
ln -s unique_name_2 hypot_current_almalinux9

We leave the old uniquely named environment there for some time, in case we need to fall back, or a specific user needs to fall back to the previous one, or just because someone may have been in the middle of using it when we setup the new one.

Discussion

This approach works well if the hashed packages involved have already been built with consistent dependencies. If not, the spack install will fail with version conflicts, and you may need to obtain or construct builds of one or more of the packages with, I.e. the same Python version, etc.

The thinking behind the new-environments-plus-symlinks approach is that it lets the user setup a consistently named entity, but lets the maintainer easily fall back to a previous state if a new version is problematic. One could just keep a single environment actually named hypot_current_almalinux9, and remove/add packages from it; but it is (1) harder to fall back to a previous good setup and (2) has a time window where the environment not is fully functional. It does however use marginally more space, and leave behind old environments that need cleanup eventually.