Telcon: 2015 05 28

Participants

Greg Lee deploying latest Python at LLNL using Spack
Matt L. and Todd are still thinking about better ways to manage/expose packages to users:

Many different scenarios where Spack needs a concept of a "package set":
- Set of packages to build ("build profile", cf. hashdist)
- Set of packages to use to concretize newly installed packages (concretization "context")
- Set of packages for an application environment (single prefix with packages used by app developers)
  - Set of packages merged into a single prefix (i.e. generalize current Python support)?
  - Set of packages in modules? Users load single module for all of them?
- Should a set of packages allow multiple of some dependencies?
  - Single environment could have two exe's that depend on different versions of a dep.
  - Should be able to coexist in a single environment unless the dep must ALSO be visible in the environment.
Not clear how the user should express all of the above scenarios
May want to postpone work on views until after 0.9, to get 0.9 out the door.
- Conclusion: Should probably only do first two bullets here for 0.9.

Spack will, by default, not display build output, and it will be logged
- Output will be logged in a file in the build directory (spack-build-output.out)
- This will be copied to the $prefix/.spack directory if the build is successful.
You'll be able to run spack -v to get the build output.

Spack will now fail fast when dependences fail to build
Issue only affected develop
Could cause incorrect builds the way it was written -- package could build before a dep.
Considering adding a similar --best-effort option to install, where DAG order isn't violated.