Telcon: 2022 03 02

Attendees

• Peter Scheibel (host)
• Wileam Phan
• Richarda Butler
• Mark Krentel
• Massimiliano Culpo
• Phil Regier
• Phil Sakievich
• David M. Rogers
• Tammy Dahlgren
• Greg Becker

Agenda items

• A spack update command
  • See https://github.com/spack/spack/issues/9134
    • The original request is to update the core/package-repo without actually installing/reconcretizing
    • There is at least one comment in there additionally requesting that such a command would update your installed packages: https://github.com/spack/spack/issues/9134#issuecomment-731296808
  • The overall idea is that users can update their Spack instance but this generally takes several commands
    • If there is a common pattern, then spack update could replace several steps with just one call
    • The issue's initial description describes a simple common pattern but has a couple of side cases worth investigating:
      • If you are on the develop branch, pull the latest state
        • If you are on another branch, fail
        • Or... try merging from develop into the branch after pulling it?
  • (Wileam) There is also the possibility to add the spack upgrade command and make spack update and upgrade behave like apt
    • If you have existing changes stash and reapply them
      • If the reapply fails, then revert the fetch (i.e. return to the commit you were at before spack update
      • What if the reapply succeeds, but the resulting logic is broken? Should there be an undo?
  • From meeting:
    • (Wileam) Instead of pulling from develop head, can we pull the latest tag?
    • (David) When pulling latest state, there was an example of an installed package description being removed
      • In other words, the new package descriptions conflict with the old installations
    • (Phil) When working with Spack, push everything into an environment
      • This avoids conflicts with git pull (or rather, in this use case there isn't any difference between spack update and git pull)
      • Treat Spack prefix as "read-only"
    • (Max) Does this make more sense when the package recipes are separated from core Spack?
      • spack update could use the latest recipes
    • (Greg) Ideally Spack is easy to use even for folks not familiar with Python/Git
      • If a common use case is to "git stash; git pull; git unstash" then users unfamiliar with git would find this problematic
      • This applies for users modifying Spack core after cloning Spack
    • (Max) The following is related but specifically to "upgrading" Spack (i.e. both pulling the latest descriptions and also reinstalling environments) - see: https://github.com/spack/spack/pull/28885
    • Summary:
      • If a user runs git pull, and it fails because of local modifications, we could have a Slack channel to answer questions related to git commands for Spack
      • Overall if git interactions can be simplified using convention, then that might be preferable to a spack update command that wraps git commands
• (David) Do users know that git pull is "the way" to update Spack?
• (Phil) Add an FAQ
  • Some things come up repeatedly in the slack channel
  • Would Stack Overflow be useful: https://stackoverflow.com/questions/tagged/spack
  • Spack discussions (on the Github page) are also useful

For next week

• Packages with multiple build systems
  • e.g. a package changes build systems for some version
  • See also https://github.com/spack/spack/pull/27021/files#diff-a69c213bdd36ddd464aa29f039985532107a6527f68c253fb5f0d204d7b462db
    • i.e. the build system is often different on Windows
  • IMO this is as simple as
    • Have a when-style clause for activating a build_system
    • When the build system is active, look for e.g. cmake_install vs. install
    • Users can just define install if they only use one build system
  • (Massimiliano) There are SEPs pending on this subject https://github.com/spack/seps/pull/3 and https://github.com/spack/seps/issues/4
• (Greg and Wileam) Proposal for nvhpc vendoring CUDA: can we delete the vendored CUDA?

Possible agenda items

• (Peter) Externals cut off dependencies: https://github.com/spack/spack/issues/9149#issuecomment-1020740273
• (Peter) Automating xcompiler for options that ought to be fed to underlying compiler for nvcc:
  • See: https://github.com/spack/spack/pull/28769#pullrequestreview-880622801
• Possible topic: Separating package repository from core
  • There are some larger changes we plan which mean we can't do this immediately
  • But we could record what is in the way and how to manage this transition
• Possible topic: new concretizer and handling of merged package repositories
  • See also: https://github.com/spack/spack/issues/28259