Telcon: 2019 05 30

Attendees

• Peter Scheibel (host)
• Tamara Dahlgren (LLNL)
• Chris Green
• Patrick Gartung
• Elizabeth Fischer

Agenda

• Python 3 support
• Recently-merged PRs of general interest
  • (Chris Green) Make .env file generated by Spack source-able: https://github.com/spack/spack/pull/11434
    • There are a couple other PRs that contributed to this as well:
      • (Seth R. Johnson): https://github.com/spack/spack/pull/11133
      • (Chris Green): https://github.com/spack/spack/pull/8476
  • (Massimiliano) Cap maximum number of build jobs based on number of cores in the machine: https://github.com/spack/spack/pull/11373
  • (Todd) Reduce coverage runs to improve response times for unit test coverage reports: https://github.com/spack/spack/pull/11411
  • (Greg) Update usage of module command: https://github.com/spack/spack/pull/8570
  • The license in all Spack files is now highly constrained - CI will report an error if the license is changed at all from the expected template: https://github.com/spack/spack/pull/11381
  • (Denis Davydov) version handling: extend Version class so that 2.0 > 1.develop > 1.1 and develop > master > head > trunk > 9999 (https://github.com/spack/spack/pull/1983)

Discussion

• Updating to Python 3
  • First issue backport libs: https://github.com/spack/spack/issues/11468
  • Second issue: we default to python2 when building, not all packages currently concretize successfully now
    • This occurs commonly because packages in python specifically request python2
    • Can some of these packages be updated to depend on python3? Perhaps not the current version in Spack
  • The second issue may be more challenging: there are many python Spack packages
    • We can pick a subset of python packages that we ensure will concretize/build successfully
    • We can choose what to prioritize for this set based on the number of edits that have been made
  • How to identify which packages are "Python 3 certified"
    • Add a comment to each verified Python package "Python 3 certified"
      • Or... add a class variable
    • Would that become a burden though? Each time a user creates a Python package they would have to record this
    • Should this be added to every current Python package
      • Should it be added to the template for Python package
    • Another option: have a format for git commit messages that indicate that the file is Python 3 compatible
      • This misses packages that we confirm to be Python 3 compatible without making changes
      • If we start by adding a "not yet confirmed" comment to each package to begin with, then the comment will be removed when Python 3 compatibility is confirmed
  • See also: https://github.com/spack/spack/pull/7926