Skip to content

Telcon: 2016 01 07

Jump to bottom Edit New page
Todd Gamblin edited this page Jan 8, 2016 · 10 revisions

Participants

  1. Todd Gamblin
  2. Mark Miller
  3. Ben Boeckel
  4. Peter Scheibel
  5. David Shrader
  6. Erik Schnetter
  7. Greg Becker
  8. Iain Morgan
  9. Alfredo Gimenez
  10. Jim Galarowicz
  11. Greg Lee
  12. Mike Collette
  13. Matt Legendre

News

  1. Multiple package repositories PR #210 is getting merged this week.

  • Will now be possible to register additional repositories.

    • spack repo add <directory> - add a package repo to Spack, record it in ~/.spack/repos.yaml
    • spack repo remove <directory> - remove a package.
    • spack repo list

  • Repos look like this:

    ```
repo-root/
    repo.yaml
    packages/
```
    • Packages that used to live at var/spack/packages/libelf/packages.py now live at var/spack/repos/builtin/packages/libelf/package.py.
    • Above will probably cause issues with some forks and PRs
    • Easy to fix -- just move the package files to the new location, and be careful about merging old PRs.

  • PR #210 adds an additional ~/spack/repos.py where your repo list is stored.

  • Also adds some changes to the way YAML is parsed:

    • Better line attribution (can tell people where their configs are wrong)
    • Schema validation with jsonschema -- allows us to easily check configs. Validation code was getting overly complicated.
  1. Cray port is mostly done -- PR #309.
  • Does compiler detection through modules on Cray platforms
  • Changes Spack's architecture field from a string to a class.
    • Each architecture can now support multiple targets (e.g., Haswell and Xeon Phi) on Cray XC40.
  • Integrates with PR #120 to provide packages in modules
  • Being used to build packages at NERSC
  • PR needs some tweaks (permission changes on package.py files, inclusion of a git submodule that should probably be made into a command)

Issues & Ongoing Discussions

  1. Spack's concretization is not making everyone happy:
  • See Issue 311. Issue 303 may be related.
  • Lots of discussion on concretization order.
  • We will probably end up changing how Spack considers installed packages when concretizing.
  1. Many discussions on how to handle Spack architecture.
  • A lot of PRs for Mac OS X don't have a good way to specifically NOT build something on Mac OS X
    • Weakness in the current spec syntax.
    • Pull 299: boolean support for when aims to fix this.
      • Will likely merge this once I get a chance to review it.
  • Another issue is that the arch is just a string right now, and it can change by site.
    • LLNL sets arch to $SYS_TYPE
      • this was mostly for expedience, and it's how we do existing installs.
      • issue is that we can't key off of SYS_TYPE in packages and still be portable outside LLNL.
    • As mentioned above, Cray PR will add notion of canonical platform with multiple targets
      • Todd proposes adding additional parameters to the platform so that we can key off network type and other properties.
        • target, e.g. haswell, Xeon Phi
        • network, e.g. myrinet, quadrics
        • others (GPU?) -- make it extensible
      • Platform attributes could be auto detected or forced.
      • Would like to establish a set of canonical arch names
        • probably from Python's platform module with some supplements
        • Spack's default arch uses this already.
  • Related issues:
  1. Greg Becker suggests adding a broken or conflicts directive
  • Packages can be marked as incompatible with certain machines/networks/etc.
  • Spack could warn earlier (currently the build will just fail).
  1. How to manage Cactus Thorns?
  • Is this similar to Python extensions?
  • Matt has a proposal:

What about making a dependency_of field, where DAG children specify their parent? The thorns would all say they are a dependency_of('cactus'), and the cactus package wouldn't have to list the multitude of children. The semantics of dependency_of() would have to be that children are only included in the DAG if they're explicitly mentioned in the spec (otherwise you'd build cactus with every thorn everytime).

You'd also have to write the cactus package to be able to fetch its list of children from Spack and generically include them in its build, but I'd think that would be feasable. ```

  • This is pretty similar to extensions
  • we should figure out how to differentiate or if it is just another type of extension.

Discussion

Add a custom footer
Clone this wiki locally