Telcon: 2021 12 22

Attendees

• Peter Scheibel
• Andrew Elble
• Asher Mancinelli
• Brian Van Essen
• Jen
• Mark Krentel
• Massimiliano Culpo
• Stephen Hudson

Agenda

• Stephen: best practices for using Python libraries in Spack (modules, views, envs...)
  • Scenario: external python, py-numpy, and py-scipy
  • When creating an env or spack load of py-numpy, complaint about missing gfortran
  • This gfortran is only available on a path that is added by an associated module
• Brian: "core_compilers" complaint when regenerating modules
  • Massimiliano: Spack generally tries to infer core_compilers
    • If it can't, then you have to define it
    • However it is also difficult to mix modules for Spack-built packages and system packages
      • TCL modules may be difficult to use in this case

Other possible agenda items

• Multiple providers of same virtual package
  • Case 1: we want blas from X and lapack from Y
  • Case 2: we actually want several instances of the same virtual (e.g. to run different instances of MPI for the same root)
• Possibly revisit: https://github.com/spack/spack/discussions/24966
  • Concerning improvements to spack develop
• Harmen (not sure if I can join): there are packages like libblastrampoline / libmpitrampoline which provide a blas / lapack / mpi interface to link to, and forwards calls to an actual blas / lapack / mpi provider lib. E.g. julia uses it to link to a blas interface for its binary deps, allowing the user to switch blas provider at runtime, avoiding abi issues. The problem is Spack only allows one provider per dag, but these packages both provides the virtual and depends on the virtual. How do we deal with this "composition" type of pattern? I was thinking: maybe we can relax unique provider per dag to unique provider per subgraph connected through link type deps? Then libblastrampoline can provide blas, and depend on blas as a run-type dependency.
  • Mark Krentel: https://github.com/spack/spack/issues/27157