Snippets Groups Projects

spack chain (#8772)

Peter Scheibel authored 6 years ago

* initial work to make use of an 'upstream' spack installation: this uses the DB of the upstream installation to check if a package is installed

* need to query upstream dbs when adding new record to local db

* prevent reindexing upstream DBs

* set prefix on specs read from DB based on path stored in install record

* check that Spack does not install packages that are recorded as installed in an upstream db

* externals do not add their path to install records - need to use 'external_path' to get path of upstream externals

* views need to check for upstream installations when linking metadata

* package and spec now calculate upstream installation properties on-demand themselves rather than depending on concretization to set these properties up-front. The added tests for upstream installations don't work with this new strategy so they need to be updated

* only refresh modules for local specs (not those in upstream packages); optionally generate local module files for packages installed upstream

* when a user tries to locate a module file for a package installed upstream, tell them to use the upstream spack instance to locate it

* support recursive upstream databases (allow upstream databases to use their own upstream databases)

* separate upstream config into separate file with its own schema; each entry now also includes a name

* metadata_dir is no longer customizable on a per-instance basis for YamlDirectoryLayout

* treat metadata_dir as an instance variable but dont set it from kwargs; this follows several other hardcoded variables which must be consistent between upstream and downstream DBs. Also update DirectoryLayout.metadata_path to work entirely with Spec.prefix, since Spec.prefix is set from the DB when available (so metadata_path was duplicating that logic)

99f35c33

99f35c33 6 years ago

Name	Last commit	Last update
.github/ISSUE_TEMPLATE
bin
etc/spack/defaults
lib/spack
share/spack
var/spack
.codecov.yml
.coveragerc
.dockerignore
.flake8
.flake8_packages
.gitignore
.mailmap
.travis.yml
CODE_OF_CONDUCT.md
CONTRIBUTING.md
COPYRIGHT
LICENSE-APACHE
LICENSE-MIT
NOTICE
README.md

Spack

Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, and many supercomputers. Spack is non-destructive: installing a new version of a package does not break existing installations, so many configurations of the same package can coexist.

Spack offers a simple "spec" syntax that allows users to specify versions and configuration options. Package files are written in pure Python, and specs allow package authors to write a single script for many different builds of the same package. With Spack, you can build your software all the ways you want to.

See the Feature Overview for examples and highlights.

To install spack and your first package, make sure you have Python. Then:

$ git clone https://github.com/spack/spack.git
$ cd spack/bin
$ ./spack install libelf

Documentation

Full documentation for Spack is the first place to look.

Try the Spack Tutorial, to learn how to use spack, write packages, or deploy packages for users at your site.

See also:

Technical paper and slides on Spack's design and implementation.
Short presentation from the Getting Scientific Software Installed BOF session at Supercomputing 2015.

Get Involved!

Spack is an open source project. Questions, discussion, and contributions are welcome. Contributions can be anything from new packages to bugfixes, or even new core features.

Mailing list

If you are interested in contributing to spack, join the mailing list. We're using Google Groups for this:

Spack Google Group

Slack channel

Spack has a Slack channel where you can chat about all things Spack:

Spack on Slack

Sign up here to get an invitation mailed to you.

Twitter

You can follow @spackpm on Twitter for updates. Also, feel free to @mention us in in questions or comments about your own experience with Spack.

Contributions

Contributing to Spack is relatively easy. Just send us a pull request. When you send your request, make develop the destination branch on the Spack repository.

Your PR must pass Spack's unit tests and documentation tests, and must be PEP 8 compliant. We enforce these guidelines with Travis CI. To run these tests locally, and for helpful tips on git, see our Contribution Guide.

Spack uses a rough approximation of the Git Flow branching model. The develop branch contains the latest contributions, and master is always tagged and points to the latest stable release.

Authors

Many thanks go to Spack's contributors.

Spack was created by Todd Gamblin, tgamblin@llnl.gov.

Citing Spack

If you are referencing Spack in a publication, please cite the following paper:

Todd Gamblin, Matthew P. LeGendre, Michael R. Collette, Gregory L. Lee, Adam Moody, Bronis R. de Supinski, and W. Scott Futral. The Spack Package Manager: Bringing Order to HPC Software Chaos. In Supercomputing 2015 (SC’15), Austin, Texas, November 15-20 2015. LLNL-CONF-669890.

License

Spack is distributed under the terms of both the MIT license and the Apache License (Version 2.0). Users may choose either license, at their option.

All new contributions must be made under both the MIT and Apache-2.0 licenses.

See LICENSE-MIT, LICENSE-APACHE, COPYRIGHT, and NOTICE for details.

SPDX-License-Identifier: (Apache-2.0 OR MIT)

LLNL-CODE-647188