Telcon: 2022 02 09
Peter Scheibel edited this page Feb 11, 2022
·
22 revisions
- Peter Scheibel
- Mark Krentel
- Massimiliano Culpo
- Tammy Dahlgren
- Wileam Phan
- Phil Sakievich
- Brian Van Essen
-
(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
- Other issue: test dependencies are discarded when a Spec is stored in the DB
- Would it make sense to have an option to treat test dependencies as run dependencies when installing
- 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
- Maestro also has a resource manager abstraction and supports user-provided scripts (https://computing.llnl.gov/projects/maestro-workflow-conductor)
- NERSC has been experimenting with https://buildtest.readthedocs.io/en/devel/ for running tests for ECP
- 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
- Generally they shouldn't need to allocate resources (since we don't have an abstraction for a resource manager)
-
(Phil) Clingo failing with externals
- (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
- (Peter) Automating xcompiler for options that ought to be fed to underlying compiler for nvcc:
- 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