Skip to content

Telcon: 2021 09 29

Jump to bottom Edit New page
Tamara Dahlgren edited this page Sep 29, 2021 · 17 revisions

Attendees

  • Todd Gamblin
  • Peter Scheibel
  • Greg Becker
  • Kayla Butler
  • Tammy Dahlgren
  • Massimiliano Culpo
  • Justin Phillips
  • Mark Krentel
  • Harmen Stoppels
  • Todd Gamblin

Agenda

  • (added topic) Greg: there are some high-maintenance files

    • asp.py
    • compiler wrappers
    • ? Should we use codeowners feature to restrict edits?
      • add a file at the root of the repo, add files and owners
      • files that have owners can't be modified without an owner reviewing
    • Folks generally agreed this would be a good thing

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

  • 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
    • 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)?

  • 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

  • (Partially covered last week, TBC later) What about packages that install some other package with them (i.e. packages with vendored dependencies)

    • E.g. Mvapich2 installs hwloc with it
    • (Mark) papi vendors libperfmon (libpfm4?)
      • hpctoolkit can work with either papi or libperfmon directly
    • In Spack we typically ask if there is an option to disable the vendoring
      • What to do when it doesn't?
        • Create a patch to remove it?
    • Would it be good to allow a Spack package to describe these additional packages that "come along" with it
    • Spack-based solutions
      • Allow mvapich to provide hwloc (as a virtual)?
      • Massimiliano added a patch for the old concretizer to allow a package to add dependency specs to a concretization

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

  • Discussion: Packages with multiple conflicting libraries - how to support them?

    • For now, any such package installed by Spack advertises just one from the set (this ensures that everything is consistent where needed)
    • https://github.com/spack/seps/pull/2
    • Brian: opencv will try to install its own openblas (which may conflict with what Spack chooses)
      • Mvapich2 installs its own hwloc
      • (Peter) I think this is a separate but still interesting problem.

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

Add a custom footer
Clone this wiki locally