Skip to content

Telcon: 2024 01 31

Jump to bottom Edit New page
Tamara Dahlgren edited this page Jan 31, 2024 · 17 revisions

Wednesday January 31st, 9am PT (UTC -8:00)

Attendees

  • Peter Scheibel (host)
  • Chris Green
  • Davide Del Vento
  • James Beal
  • Jakov Petrina
  • Jonathon Anderson
  • Kyle Knoepfel
  • Mark Krentel
  • Massimiliano Culpo
  • Srinath Vadlamani
  • Tammy Dahlgren
  • Wileam Phan

Agenda

There are no pre-planned agenda items: this meeting is just for Q&A

  • James: can a new Spack use old packages?
    • Peter: yes: we only ever produce package compatibility issues on major release
      • And we want to support use of older package installations (i.e. if you have issues using older installed packages, please file it as a bug)
      • Concretization behavior is likely to change
    • In terms of binary caches, those generated by older Spack can become incompatible with newer Spack
    • You can also point a new Spack at an old Spack installation
  • Jonathan:
    • Added a module as an external
    • CMake was picking up the oneapi tbb vs. the Spack tbb
    • The module intel provided for oneapi set things like TBB_ROOT=...
    • Spack's TBB package does not set TBB root
    • We can also unset *_ROOT variables
    • See: https://github.com/spack/spack/pull/30015 (this is about removing all env variables)
    • Peter: it might be hard to distinguish TBB_ROOT being set by oneapi vs TBB (in the latter case, we probably want it)
    • Should we warn if *_ROOT variables are set
      • Peter: worried about this: if we take this approach for all of these types of problems then we accrue many warnings that users have to ignore
    • Peter: can this be solved by replacing the module-based external with prefix-based?
      • Jonathan: yes, but if the modules are loaded at the time of the Spack invocation, Spack doesn't clear the module variables
  • Wileam:
    • Is there a way to symlink an external package into a view?
      • No because it could be in /usr
      • Could a package list out the individual files relative to the prefix
        • That would work (Spack could then pluck the right files out of /usr)
        • Wileam: Although the installation locations could change over time, so this would create a maintenance burden
    • Peter: In this case I assume the external packages would be part of PATH etc.
      • Jonathan: this relates back to the TBB module issue above
      • Peter: note that modules don't affect view operation, so we could possibly dissociate view/install-time env handling
    • (Unnecessary) Peter, we could view activate (or env activate) and then spack load the-external to get the external in your path
      • Jonathan: We activate the env, we already see the external prefixes added to PATH
      • The primary issue is with using modules with the externals
  • Kyle: testing github PRs
Add a custom footer
Clone this wiki locally