Telcon: 2022 11 16

Held Wednesday Nov. 16th, 9am PT

Attendees

• Peter Scheibel (host)
• Mark Krentel
• Massimiliano Culpo
• Umashankar Sivakumar
• Phil Sakievich

Agenda

Note SC is this week so there are no general topics planned: just Q&A

• Mark Krentel: What is the minimum Python version that will be able to run Spack going forward?
  • 3.6
  • What about the Python versions that Spack can install?
    • See: https://github.com/spack/spack/pull/33898
      • "As of this PR, Python 3.7+ is the minimum version of Python that Spack can install"
  • Does the Python used to run Spack need headers?
    • Yes if bootstrapping from source (you can also bootstrap from binaries, which does not require it)
    • If you are using an external Python package, other packages that depend on it may need the headers
• Massimiliano: would it make sense to provide a Spack artifact that comes with a Python interpreter?
  • It could also include Clingo (so no bootstrapping needed)
  • This would allow us to make sure that Spack can run on any system it is downloaded (as long as the interpreter can run on it)
  • Phil: that would be useful
  • This could probably be done for a limited number of distros. Supporting it for all platforms might be difficult.
  • Massimiliano (not added after meeting): There is work from Harmen that can be reused https://github.com/eth-cscs/spack-batteries-included
• Umashankar: if we push a PR to Spack, but don't want the Spack team to merge it "yet", is that allowed?
  • Yes: you can prefix the title with [WIP] and mark it as a draft
• Umashankar: would Spack be a good fit for Google's Summer of Code event?
  • It seems like it would be really useful for Spack
• Massimiliano: how much would people be bothered if the command spack unit-test didn't work "out-of-the-box" but required some bootstrapping
  • Looking at vendored dependencies: most of them are needed for testing
  • When updating pytest, it has accumulated many dependencies so it would be nice not to vendor them anymore
  • If we handle installation of Spack testing dependencies in the bootstrap process, what is the difference to the user compared to vendoring them?
    • Only on systems where bootstrapping fails (this relates to above points about why the installer would be useful)
• Phil: why is the bootstrapping store separate? I want to use some of the packages that Spack installed for other purposes
  • Massimiliano: spack uninstall -a would force you to re-bootstrap in this case
  • Phil: what if the bootstrapped packages were in an upstream?
    • The only place where an issue would come up is if a user uninstalls/removes packages from the bootstrap store
• Phil: https://github.com/spack/spack/issues/33899
  • Possible issue where the upstream installs packages that the local Spack instance doesn't know about?