Skip to content

Telcon: 2017 01 08

Jump to bottom Edit New page
Elizabeth Fischer edited this page Jan 5, 2017 · 5 revisions

Participants

  1. Todd Gamblin (LLNL)
  2. Elizabeth Fischer (NASA GISS)
  3. Cyrus Harrison (LLNL)
  4. Jim Amundsen (Fermi)
  5. Patrick Gartung (Fermi)
  6. Greg Lee (LLNL)
  7. Mario Melara (NERSC)
  8. Peter Scheibel (LLNL)
  9. Tom Merrick (TAMUCC)

News

  1. As usual, check the pulse

  2. Down to last few issues for Spack v0.10 release

  • Todd is vowing to have v0.10 out by next week.
  1. Major point of discussion: what to do about Java and other EULA-requiring packages. Discussion in #1298 and #2621

  • Spack currently auto-accepts the license in the jdk package

  • Homebrew does this as well

    • put in an issue to homebrew-cask -- neither tool should be doing this and they don't have any special deals with Oracle.

  • Debian and Gentoo have mechanisms for silently accepting certain types of licenses.

    • Key is that the user makes the decision to accept these licenses.

  • Todd discussed this with LLNL management and they recommend a system as follows:

    1. Close #1298 and postpone solution to 1.0 (Feb)
    2. For 1.0, implement a licenses.yaml file with license preferences similar to Gentoo's
    • This would be coarse-grained -- packages are either:
      • free (default, includes most OSI licenses)
      • EULA (requires a specific entry in licenses.yaml to accept).
    1. EULA Packages would contain a URL or some pointer to the license, and users would need to say "accept" interactively on install if they accept the license.
    2. Also add a spack license command that would allow easy adding of settings to the file, e.g., notionally:
    spack license accept --always jdk@:1.8

    You could use regular old specs to restrict the version on what you accept.

  • Thoughts?

  1. Some work on 1.0 has also started:
  2. Spack now has a CDash site at spack.io/cdash - We will be using this to test the 1.0 release - Todd is currently hosting this site himself. We will move it to LLNL infrastructure once public cloud web hosting in AWS is approved. - Kiel Friedt at LLNL is working on a YAML format to specify combinatorial tests to Spack. - See #2014 and #2445
  3. Spack has a domain at spack.io - Put up a simple Jekyll splash page there with pointers to the rest of the project. - cf. brew.sh and linuxbrew.sh

Discussion Topics from Elizabeth

  1. Integration with other package mangers. (#2750)

  2. Mine other repos to auto-generate and auto-maintain packages AND THEIR DEPENDENCIES. [speculative]

  3. Todd: This is a cool idea but do we want to maintain all this stuff? - Interested to see what type of auto-import can be done - We may want to have interested parties maintain some of these larger ecosystems (e.g. npm) outside the core - look at http://libraries.io -- aggregator for package managers / tracker for dependencies

  4. Jim: PyPI integration could be very useful

  5. Flexible Spack Environments for Development

    1. Override config with custom scopes (#2686)
      • OS-specific settings in /packages.yaml Eg: buildable=False stuff
      • Project-specific settings in /packages.yaml Eg: Specific versions, some variants, etc.
      • Sub-project settings in /packages.yaml
      • Develop-mode settings in develop/packages.yaml Eg: Turn versions to develop, turn on +debug variants
    2. "Bundle" (Dummy) packages: no PR yet
    3. Integrated creation of enviornment scripts (#2698)
    4. spack setup that generates multiple spconfig.py files at a time (#2664)
    • Todd: Seems like Jim's SpackDev, spack setup, this SpackEnv support, LLNL code team needs, and Matthew Krafczyk's work at NCSA overlap a lot
      • need for swappable environments
      • need for integration with development environment, potentially for multiple projects
        • multi-package spack setup does some of this
        • Jim to look at spack setup
        • Todd to look into a face-to-face and/or skype meeting about development environments in Spack.

  6. Bugs found when merging configurations (#2694) ---> More thought needs to go into HOW to merge variant lists

  7. Command line defaults (just make life easier) (#2705)

  8. Global Variant: shared vs. static (#2692) Intended use: set for all of Spack in packages.yaml (#2644) No way to mix shared & static within one concretization --> Are we OK with this (requires #2386 first)

  9. Many pending documentation needs

    1. Especially CMakePackage/AutotoolsPackage/PythonPackage

  10. Other variant standardizations:

    1. +doc (not +docs)
    2. Lower case (esp. +x)
    3. Underscores, no dashes (at least for forseeable future)

1.type=nolink

  1. Agreed to deprecate in favor of type=('build', 'run')

Other Discussion

  1. Mario from NERSC:
  • met with consultants about Spack
  • worried about static-izing many of the packages -- we'll need to settle the static/shared variant discussion Elizabeth mentioned
  • also need to make sure packages will build static.
  • static global variant should be included in combinatorial testing for 1.0
Add a custom footer
Clone this wiki locally