-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Telcon: 2023 03 29
Peter Scheibel edited this page Mar 29, 2023
·
19 revisions
Held Wednesday March 29th, 9am PT (UTC -7:00)
- Peter Scheibel (host)
- Jack Morrison
- Justin Cook (NERSC)
- Mark Krentel
- Massimiliano Culpo
- Steve Leak (NERSC)
- Tammy Dahlgren
(20 minutes at the end of the meeting is reserved for Q&A)
- Justin Cook: Best way to deploy Spack on a system?
- e.g. does each user get their own copy of Spack?
- yes to that specific question
- See: https://github.com/spack/spack-configs
- This includes example configs from a number of sites
- In general the approach I'd recommend for an admin providing for several users:
- all users clone Spack
- the admin prepares a set of configs and environments
- these can include things like external (system) package installs
- also things like permission settings
- you may also want to provide a customized binary cache
- Justin: concern if everyone has their own version of Spack about synchronizing the commit used by spack
- Have a module for spack which sets some environment variables
- Admins share a spack instance and use it to install software for users
- Unnecessary duplication of Spack files
- Examples of current pain points with shared Spack:
-
spack edit
fails if it ends up targeting the global repo
-
- See: https://github.com/spack/spack/pull/11871
- Steve: overall system
- There is an upstream which is used to provide shared
- Environments are created by default in the spack prefix
- For now, the workaround is to prevent users from creating named environments
- Patch needed: at some point during the install, Spack changes permissions/ownership for installed prefix
- TODO: resolve over slack (see the patch diff and errors without patch)
- Tammy: related permissions handling PR for multi-user Spack: https://github.com/spack/spack/pull/16614
- See replacement PR: https://github.com/spack/spack/pull/19994
- e.g. does each user get their own copy of Spack?
- Jack: built in utilities that allow me to take action on the age of an installation
- Massimiliano:
spack find
can search for installations that fit in a time window (see--start-date
and--end-date
)
- Massimiliano:
- Mark: is there a way to specify a version as the latest
spack install dyninst@latest
- Don't want
@develop
in this case, want the latest fixed revision - This overrides "preferred"
- Moreover, this is not a preference, but rather a hard constraint
- E.g. in
packages.yaml
could ask fordyninst@latest
- In particular if there is reuse, we want to use later versions
- Does
spack concretize -U
help with this? - Reuse mode: dependencies
- For an environment this means that explicitly-listed specs do not prioritize reuse, but dependencies are reused
- Does
- See
visit
: in which case the latest version is deprecated - Would it work to say "preferred versions are required for this specific package"?