Telcon: 2022 03 02

Attendees

• Peter Scheibel (host)
• (TBD: whoever wants to discuss Spack issues)

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?
• 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

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