recommendations

Types of Spack instances versus padding

Because we want folks to use prebuilt binaries for the most part, we want to build packages that can reliably be relocated by Spack. This currently involves turning on install-root padding; we currently recommend setting that value to 255 (padded_length: 255 in config.yaml) in Spack instances where software is being built for distribution. By choosing a common padded_length, we can use other prebuilt packages in these instances, but also redistribute things built in it. However, the current implementation of this makes it difficult for users trying to find software by browsing the filesystem, and leads to Really Long $PATH and other similar issues for end users, so we recommend that Spack instances setup for end-users to use software (i.e. in /cvmfs/) be configured without padding. [Possible alternative, always use padded_length: 255 and include a padded_root symlink in the Spack instances for the convenience of those browsing the source tree -- still have Really Long Paths if folks are using spack load, etc.]

Summary:

use	padding
building	255
use	0

Another common case is service development/deployment Spack instances, where we may have additional packages and recipes not found in our usual spack distributions. Any custom packages for these instances should still be built in a separate spack instance with padding, and installed in the actual service development/production instances via a buildcache which is distinct from the stock buildcache areas, so that the packages don't cause confusion with users who don't have the recipe repositories for them. Then service developers can add the spack recipe repository **and **the buildcache of packages built with those recipes to their Spack instances. This way we have a way to reproduce the production/development environments exactly.

Use of environments

Spack provides environments for providing easy access to a specific subset of software; we recommend people

• use named environments with useful names "myexperiment_reco_production_2022-08-01" or "service_production_v3_4"
• keep track of current/preferred environments with symlinks like "myexperiment_reco_production_current". (should we recommend this? I believe this works currently, but you have to add the symlinks by hand...) This allows "instant" switching of preferred versions.
• People can use the spec.yaml file for an environment to generate a new environment for a new version, etc.