Brett's use cases

Use cases

Use cases for environments are loosely broken down by the role they may affect.

General

General use cases that don't have a role (or, make a new role section).

Users

These are use cases that affect or are by end users.

1. I create a central Spack area. I don't use Environment Modules but something similar. I want to generate configuration files my env system for the Spack packages I install. I can write a local script using Spack YAML files.

2. I create a central Spack install area. My users don't want many options so I create a releaseXYZ/ directory and make a spack view in each corresponding to the desired package versions. Some users just want a single release so I maintain new, pro and old (hi CERNLIB!) symlinks to the most recent releaseXYZ directories.

Installers

Use cases relating to people running spack to do the installation.

Software Developers

Use cases for people that develop software in an environment that may include Spack in some way.

1. I create a central Spack install area for both "external" packages E1, E2, E3 and releases of packages that my group develops, G1, G2, G3. Assume G1 depends on E1, G2 on E2, etc and G3 depends on G2 which depends on G1.

   One developer wants to make changes to G2 while otherwise using packages from the central install area. He needs to build G2 locally, linking against central G1, E1, E2. He would like to an executable from the central G3, link against his G2 library without having to rebuild G3.

   Another developer finds a bug in G3 and requires it and E3 to be rebuilt with debug symbols. Otherwise, she wants to continue to use the central build for the other packages. She needs to be able to run executables from G3 under GDB so that source code from her copy of G3 and E3 are found and ideally so that source used to build the centrally installed packages can also be found by GDB.