Telcon: 2021 10 13

Attendees

• Todd Gamblin
• Peter Scheibel
• Mark Krentel
• Gregory Becker
• Kayla Butler
• Massimiliano Culpo
• Phil Sakievich
• Richard Henwood
• Tammy Dahlgren
• Srinath Vadlamani
• Nick Sly

Agenda

• Greg/Harmen: versions https://github.com/spack/spack/discussions/26557

  • Peter: what about foo<4 string conversion to foo@:3.999?
  • Greg: what about "foo@3.*" ("I want any version 3")?
    • Mark: or foo@3.+ (doesn't require quoting in the shell)?
    • Nick: what about foo@3.?
      • In this case you'd have to ask for appleclang@11.
  • Harmen: what about foo@=3 ("I want exactly version 3, even if there's a 3.0")?
    • Greg: each time you use a compiler with different fortrans but the same compiler
    • %appleclang@11.0.0-gfortran
    • %appleclang@11.0.0
    • Spack treats compiler versions as exact but not package versions
  • Greg: why not have foo@3 mean "exactly 3"?
    • And then users who want 3.x can ask for foo<4
  • If we have 3:3 mean "exactly version 3", then this would break packages which treat the upper bound as being 3.x
  • Harmen: not worried that 3:3 means 3:3.999
    • This is unambiguous
    • The original concern was the inconsistent treatment of @3

• Todd: reuse concretizer is working well for both reuse and build specs

  • It will be in 17.0
  • (along with the "new" concretizer being the default)

Things to be discussed in future meetings

• (Added this week) Mark Krentel: issues with Clingo concretization. In particular with virtuals.

  • Currently in slack, not github
  • Greg: virtual versions are not properly forwarded to provider versions

• Phil Sakievich: spack develop questions about direction

  • See also:
    • https://github.com/spack/spack/discussions/24966
    • https://github.com/spack/spack/issues/26295#issuecomment-931277758
    • https://github.com/spack/spack/pull/22087
    • https://github.com/spack/spack/pull/25981

• Peter: when is the user scope necessary?

  • I've asserted we need it in some cases
  • For shared filesystems, it can be very annoying though, so I'd like to figure out if it could in fact be removed entirely
  • If using spack without an env, then there's a question of where to write config data to
    • ~ is an obvious choice
    • There is also a PR which introduces an install-tree scope, which would be owned by the user

• Tammy: should we build (and retain) the test dependencies at concretization/build time, especially if --test is used?

  • If not, there a potential issue with inconsistent test dependencies used to run tests at build time versus those used for stand-alone tests.
    • This has been observed with dependencies such as CMake (versions).
  • TBC next week
  • If you concretize at test time (vs. build time) then this depends on reuse in the concretizer

• Discussion: Packages which require multiple build systems: how to handle them?

  • Discussions on this:
    • (Proposal based on using a new directive) https://github.com/spack/seps/blob/8dafadb4cae08275d168af964b3d168b4248977f/seps/sep-0002.md
    • (Notes on trying an approach based on a when class decorator) https://github.com/spack/seps/issues/4
  • Two approaches were covered: Greg thought there were issues with both; we will cover that this week.

• Discussion: long environment activations - are you having an issue with this?

  • Some large envs might have this problem, e.g.: https://github.com/spack/spack/issues/25555

• Discussion: what does it mean to set a preferred variant in packages.yaml?

  • See discussion in issue https://github.com/spack/spack/issues/24754