Skip to content

Telcon: 2017 05 11

Jump to bottom Edit New page
Elizabeth Fischer edited this page May 11, 2017 · 10 revisions

Attendees

  • Elizabeth Fischer
  • Greg Lee
  • Jim Amundson
  • Kiel Friedt
  • Patrick Gartung
  • Ben Boeckel
  • Brett Viren

Resources

Environments proposal here: https://github.com/LLNL/spack/wiki/Environments-Road-Map

Google groups discussion here: https://groups.google.com/forum/#!topic/spack/ECirfnwHXlo

Spackdev motivation: http://compacc.fnal.gov/~amundson/spackdev-readme.html

Agenda

  • Cover use cases
    • Discuss: do any of them seem uncommon?
    • Were any important use cases missed?
    • Are there any particular important special conditions in your set up for a given use case?
  • Discuss road map
    • Some changes will be more difficult, e.g. require updates to the concretizer
    • There may be some simple changes that for example help users avoid cases where they have X->Z and Y->Z'
  • Discuss command syntax

Discussion

  • Todd has expressed a dislike for the ordered nature of the spec list
    • plus: if a spec list has order then it is easy to concretize based on what came before
    • minus: cannot concretize in parallel

[Elizabeth: As currently envisioned, the "order" of the spec list is actually a priority, which will be used in two ways: (1) When creating a view of module and there are conflicts, determine which version of a package is included in the view/module, (2) When concretizing based on other stuff in the spec list, this enforces a partial order on concretization. If option (2) is not turned on (as things are today), then concretization can proceed entirely in parallel.]

  • I am of the opinion that when building an environment for users to build against, both the view and module based method for setting up environments will both require support for ensuring that if X->Z and Y->Z that you dont build different instances of Z for each

  • Elizabeth: spack --spec-list=L1 install vs. spack install --spec-list=L1

  • Or better yet... include a set of configuration YAML files in each spec list. packages.yaml is critical to getting Spack to install the stuff I need.

  • One module for entire environment, named after the spec list.

  • Use case 4: Wouldn't it be cool if Spack could create a top-level "make" command that would make A and C. This could be especially useful for some HPC applications that are structured as a large number (>12) packages.

Add a custom footer
Clone this wiki locally