(Suggestion for next week) Greg/Harmen: versions https://github.com/spack/spack/discussions/26557

(Suggestion for next week) Phil Sakievich: spack develop questions about direction

• See also:
  • https://github.com/spack/spack/discussions/24966
  • https://github.com/spack/spack/issues/26295#issuecomment-931277758
  • https://github.com/spack/spack/pull/22087
  • https://github.com/spack/spack/pull/25981

Resolving discrepancies between spack load, module load, and spack env activate

• See: https://github.com/spack/spack/discussions/26266

• Discussion point: Greg pointed out that some link-type deps require env variables to be set (MY_CONFIG_FILE=/path/to/path.ini or so). This implies calling setup_run_environment on that dep. One solution is to make the dependent add a (run, link)-edge instead of just link edge, but it doesn't seem like it's the dependent's responsibility. So: should setup_run_environment be called on each transitive link type dep too (and run type deps of link type deps)? What is the difference between link/run type deps then, really? Just that only-link-type deps prefix paths aren't added to PATH?

• Autoloading modules by default?

  • This would make Spack modules work like spack load

• Harmen: what is the difference between link/run dependencies

  • See also: https://github.com/spack/spack/issues/3768
    • See also: https://github.com/spack/spack/pull/18365
      • Tammy: should we always be installing test dependencies (for running tests after install)
      • Greg: keep them abstract?
        • And then concretize them at test time (reusing dependencies)

• Greg: the modules we generate have to work if loaded directly or transitively

  • spack load could differentiate between loading roots and loading dependencies
    • However, it collects specs upfront so essentially loads each as a root (but is that intentional)?

• Greg: lmod and TCL 4 may both support reference counting when it comes to loading dependencies

  • It would be good to add this if autoloading by default
  • Let's say you load mpich, and unload it, then all the dependency modules are not unloaded
  • Massimiliano: if you load two things with the same dep, and then unload each along with deps, then without reference counting

Harmen: do we autoload external modules?

• Greg: Spack creates its own modules for externals
  • Greg: We should probably explicitly load the system-provided module
  • This is hard to integrate with the existing lmod hierarchy
    • Massimiliano: some of the difficulty is related to the naming conventions used in the lmod hierarchy
  • This might be easier for TCL modules

Harmen: when you swap between Cray programming envs, is there a way to automatically change the config?

• https://github.com/spack/spack/pull/26341
• Related: if we use env variables to control user/system scopes, then this also offers an option to "avoid" using a scope
  • Todd apparently had objections to prior PRs that do this

Cray cross-compiling issues (we touched on this during the meeting)

• Mark: main source of issues on Cray is the frontend/backend distinction (for their tool, some must be compiled on FE, and some on the BE)
  • It would help to have access to multiple sets of compilers for one build
    • This only works when the FE/BE architectures are "similar enough"
  • Greg: similar issue on Fugaku (desire to build dependencies twice: once for FE and once for BE)
• Greg: we're a couple features away from working on this
  • Separate concretization of build deps
  • Compilers as dependencies
  • Once those are done, cross-compile support is easier (build/run split across FE/BE)

Tammy: should we build (and retain) the test dependencies at concretization/build time, especially if --test is used?

• If not, there a potential issue with inconsistent test dependencies used to run tests at build time versus those used for stand-alone tests.
  • This has been observed with dependencies such as CMake (versions).
• TBC next week
• If you concretize at test time (vs. build time) then this depends on reuse in the concretizer

Discussion: Packages which require multiple build systems: how to handle them?

• Discussions on this:
  • (Proposal based on using a new directive) https://github.com/spack/seps/blob/8dafadb4cae08275d168af964b3d168b4248977f/seps/sep-0002.md
  • (Notes on trying an approach based on a when class decorator) https://github.com/spack/seps/issues/4
• Two approaches were covered: Greg thought there were issues with both; we will cover that this week.

Discussion: long environment activations - are you having an issue with this?

• Some large envs might have this problem, e.g.: https://github.com/spack/spack/issues/25555