Telcon: 2022 02 09

Attendees

• Peter Scheibel
• Mark Krentel
• Massimiliano Culpo
• Tammy Dahlgren
• Wileam Phan
• Phil Sakievich
• Brian Van Essen

Agenda

• (Peter) Deptype for running tests after a build

  • See also: https://github.com/spack/spack/issues/3768#issuecomment-293046651
  • (Greg) test dependencies should be kept as stubs and then only built when the user wants to run the tests (which may be an arbitrary amount of time after the user installs the package to be tested)
  • There are a number of different related issues:
    • Should test dependencies be added when activating an environment
    • We want to enable a user to run tests after building (but the test deptype doesn't allow that) and we want to allow users to install the package without having to install expensive dependencies needed only for tests
  • What are some general expectations for smoke tests on Spack packages
    • Generally they shouldn't need to allocate resources (since we don't have an abstraction for a resource manager)
      • The idea being that if you do an installation on a login node, more-intensive tests may use too many resources on the login node
      • Flux may define abstractions that help with integrating resource managers into a Spack test workflow
    • For tests involving allocations, users may need to specify a queue
      • There's a tool called Pavilion
    • Running a test may involve accessing a large dataset that is produced in an ad-hoc manner (not available as a Spack package) or rely on the temp directory

• (Phil) Clingo failing with externals

  • https://github.com/spack/spack/issues/28201

• (Peter) Externals cut off dependencies: https://github.com/spack/spack/issues/9149#issuecomment-1020740273

• Possible continuation from https://github.com/spack/spack/wiki/Telcon%3A-2022-01-26: vendored dependencies

  • (Andrew) nvhpc installs CUDA, so which CUDA is being used if I install nvhpc with Spack?
  • (Wileam) Should nvhpc be modularized like oneAPI? This would partially solve the embedded CUDA issue, I think

• 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/28260