Telcon: 2016 05 12

Participants

1. Todd Gamblin (LLNL)
2. Jim Amundson (Fermi)
3. Jim Galarowicz (Krell)
4. Kelly (KT) Thompson (LANL)
5. Greg Lee (LLNL)
6. Patrick Gartung (Fermi)
7. Matt Belhorn (ORNL)
8. Peter Scheibel (LLNL)
9. Benedikt Hegner (CERN)
10. Robert French (ORNL)
11. Mike Collette (LLNL)
12. Mario Melara (NERSC)
13. DJ Deo (Kitware)

News

1. Update from HEP Physics workshop. (Benedikt) See 2pm session here

• Spack session was parallel with ML session
• What was discussed?
  • Patrick presented
  • Q/A session
• ~40 people attended Packaging session at HEP workshop
  • 2 critical people in audience; most interested in exploring further
    • 2 critical people were from another package manager team
      • LCGCMake (LHC computing grid) pkg manager on top of CMake using external package add
    • Conda was also mentioned
      • doesn't have versioning over time.
• Still features to add, but can work on this later

New contributions, features, etc.

1. Many PRs merged this week -- see Pulse for a complete list in case I missed some.
2. Merged #375 so that PRs are now checked for code style and coverage.

• Spack is using PEP8, mostly, but ignoring some rules that prevent lining things up nicely.
  • Biggest thing is probably the 79 char limit on lines, with url = lines in packages exempted.
  • use share/spack/qa/run-flake8 to run formatting checks locally, for now.
    • Spack command (spack audit?) forthcoming.
• Test coverage of 64% indicates we could probably do better.
  • this number doesn't include package coverage
  • should we include spack commands in test coverage? I think so but no good harness for that yet.
• Bigger issue: Brett Viren has had issues with testing spack commands
  • put scripts in to test spack commands
  • need a better way to test the commands themselves.

1. Massimiliano Culpo's module customization PR #744 has been merged.

• docs are generated and online

1. Kudos from Elizabeth Fischer (who couldn't make it today) to Brett Viren on #869

• Looks forward to seeing this go in!
• Lots of people like this PR -- Todd still needs to review it but it looks great!
• Elizabeth closing #721 as it is superseded by #869

1. Merged extensive support for licensed software thanks to Adam Stewart in #558

• Greg Lee working on rebasing his Intel support on top of that.

1. lots of documentation PRs (some only docs!)
2. Configurable Spack installation prefix (hegner)

• Brett wants per-repo config (/etc/spack)
• Benedikt suggests letting user pick what precedence the user scope has.

1. Importable Spack (Viren)

Updates

1. cflags going in (finally after some delays); hashes will change so expect rebuilds.
2. Newarch/Cray update (Greg, Mario)
3. RPM generation progress update (Peter Scheibel)

• feature added to allow not installing particular dependencies as RPMs when generating with Spack.

1. Qt5 with mac support soon to be merged (DJ)

• F811 getting picked up as error due to install() and @when decorators

1. Elizabeth is interested in making Spack faster

• need more developer documentation to make this easier
• internals of spack are currently not well documented, particularly specs/concretization
• should also document some future plans (e.g., better constraint solving)

Other suggestions

1. Request to extract Spack's which and Executable support for Popen into its own library.

• sounds good in principle
• Anyone interested?

Discussion

1. Benedikt:

• Binary packaging PR is feature complete.
  • Brute force re-RPATH's packages and text files with new install prefix
  • not truly "relocatable" yet
  • looking at making Spack install relocatable packages
  • relative RPATH breaks down for RUNPATH
• Patrick Gartung has tested it on El Capitan
• Benedikt will clean up implementation and tell us to look at the PR

1. Kelly Thompson:

• Los Alamos very interested in Cray support
• Very interested in module support for preinstalled compilers
• One other question:
  • What about Intel MKL support
    • Greg Lee should have his MKL package in by EOD today.

1. Jim Amundson:

• still working on developer-oriented system for Spack ("spack-dev")
  • sets up a development area and copies scripts out of Spack to build like spack would.
  • not quite ready yet; will send to the list when ready.
• looking for a better name.
  • spack-dev is difficult to use in conversation