Telcon: 2019 04 11

Attendees

• Peter Scheibel (host)
• Chris Green
• Patrick Gartung
• Dan Topa

Agenda

• 1:00-1:30pm PDT: discuss whatever anyone wants to bring up
• 1:30-2pm PDT: discuss items from HEP documents in Slack #hep channel

Recently-merged PRs of interest

• Documentation for Spack chain (pointing one Spack instance at another): https://github.com/spack/spack/pull/11152
  • The chain feature was added a couple weeks prior: https://github.com/spack/spack/pull/8772
• Environments now automatically maintain a view, and activating the environment adds that view to your $PATH etc.: https://github.com/spack/spack/pull/10017
• (Massimiliano Culpo) Spack can be extended with new commands: https://github.com/spack/spack/pull/8612

HEP Documents Discussion

Executive Summary

• Regarding section 5
  • This would be satisfied by modern Spack-dev
  • The idea is to support the developer use case
  • Developing multiple packages simultaneously
  • If a DAG has several packages with develop versions, then you could just do a force reinstall on any of them to do install-in-place
• Sections of executive summary which Spack leaves to be desired
  • Section 5 (noted above)
  • Requirements placed by someone managing multiple releases (not directly covered here but this "topic" is not currently well-handled)

Work Items

• 2.1.3 flake checks on external: currently they aren't integrating Spack imports
  • Does adding it to PYTHONPATH work
• 2.1.2 is addressed by PR 11145
  • TODO: address this
  • Relatively high priority
• 2.3
  • Can specifying packages by hash work for this?
    • They want the flexibility to use older packages as long as they are suitable
  • If someone adds a variant, and for example it defaults to false, then we may assume the old package is identical, but the hash will change
  • "If package X depends on Y and doesn't explicitly mention whether it needs Y+foo or Y~foo, then we can say that an older version of Y without any variant "foo" would be suitable"
    • This would be sufficient for reusing locally-installed packages but would initially be unsuitable for pulling from binary caches, since they are hash-based
    • However, once package reuse is added to the concretizer, this will likely be simple: cache packages are another form of preferred package (like locally-installed packages)
  • Can chains be considered higher priority, or relaxing the rules when considering upstream packages

HEP - For next time

• Start at section 2.5 - no-source packages
• How to get an absolute versions and absolute version

Other notes from meeting

• Spack's notion of build-time dependency
  • Package that's only needed at build time
• What about header-only packages?
  • For now you should mark these as link deptype
• See: https://github.com/spack/spack/issues/3768
• What about "catch"
  • In the Spack repo
  • Not actually covered by any existing or proposed deptype: it is a unit test header-only framework, so packages using it will need to build their tests and include the catch include/ dirs
  • For now perhaps we can handle this by getting dependencies to call .headers on the catch package to manually add it
  • We can add a deptype but generally I think keeping them limited is ideal for clarity