summaryrefslogtreecommitdiff
path: root/share
AgeCommit message (Collapse)AuthorFilesLines
2022-05-05spack external find: add search path customization (#30479)Greg Becker1-1/+1
2022-05-04gitlab: Remove temporary storage url from all stacks (#29949)Scott Wittenburg7-10/+2
Gitlab pipelines run for spack already have other S3 storage locations configured for storage of binaries, so this PR removes the redundant per-pipeline mirror. As a result, the "cleanup" jobs will no longer be generated at the end of each pipeline, removing one possible point of pipeline failure.
2022-05-04Remove deprecated "--run-tests" option of "spack install" (#30461)Massimiliano Culpo1-1/+1
2022-04-28Delocalize type output for bash completion (#30360)lpoirel2-2/+2
2022-04-28Add command for reading JSON-based DB description (now with more tests) (#29652)Peter Scheibel1-2/+6
This is an amended version of https://github.com/spack/spack/pull/24894 (reverted in https://github.com/spack/spack/pull/29603). https://github.com/spack/spack/pull/24894 broke all instances of `spack external find` (namely when it is invoked without arguments/options) because it was mandating the presence of a file which most systems would not have. This allows `spack external find` to proceed if that file is not present and adds tests for this. - [x] Add a test which confirms that `spack external find` successfully reads a manifest file if present in the default manifest path --- Original commit message --- Adds `spack external read-cray-manifest`, which reads a json file that describes a set of package DAGs. The parsed results are stored directly in the database. A user can see these installed specs with `spack find` (like any installed spec). The easiest way to use them right now as dependencies is to run `spack spec ... ^/hash-of-external-package`. Changes include: * `spack external read-cray-manifest --file <path/to/file>` will add all specs described in the file to Spack's installation DB and will also install described compilers to the compilers configuration (the expected format of the file is described in this PR as well including examples of the file) * Database records now may include an "origin" (the command added in this PR registers the origin as "external-db"). In the future, it is assumed users may want to be able to treat installs registered with this command differently (e.g. they may want to uninstall all specs added with this command) * Hash properties are now always preserved when copying specs if the source spec is concrete * I don't think the hashes of installed-and-concrete specs should change and this was the easiest way to handle that * also specs that are concrete preserve their `.normal` property when copied (external specs may mention compilers that are not registered, and without this change they would fail in `normalize` when calling `validate_or_raise`) * it might be this should only be the case if the spec was installed - [x] Improve testing - [x] Specifically mark DB records added with this command (so that users can do something like "uninstall all packages added with `spack read-external-db`) * This is now possible with `spack uninstall --all --origin=external-db` (this will remove all specs added from manifest files) - [x] Strip variants that are listed in json entries but don't actually exist for the package
2022-04-28build_env/test_env: add concretizer args (#30289)Greg Becker1-2/+2
2022-04-27e4s ci: uncomment umpire (#29776)eugeneswalker1-1/+1
2022-04-26spack spec: add '--format' argument (#27908)lorddavidiii1-1/+1
2022-04-25Environments: add flag to skip printing concretized specs (#30272)iarspider1-1/+1
With an active environment, you can now run "spack concretize --quiet" and it will suppress printing the concretized specs.
2022-04-22Update Dockerfiles and images for Spack v0.18.0 (#30216)Massimiliano Culpo13-411/+46
This PR updates the list of images we build nightly, deprecating Ubuntu 16.04 and CentOS 8 and adding Ubuntu 20.04, Ubuntu 22.04 and CentOS Stream. It also removes a lot of duplication by generating the Dockerfiles during the CI workflow and uploading them as artifacts for later inspection or reuse.
2022-04-20refactor powershell setup to make it sourceable (#29987)Tom Scogland1-0/+61
* refactor powershell setup to make it sourceable * only set editor if it is unset * change directory to spack root in subshell * Update share/spack/setup-env.ps1 Co-authored-by: John W. Parent <45471568+johnwparent@users.noreply.github.com> Co-authored-by: John W. Parent <45471568+johnwparent@users.noreply.github.com>
2022-04-19Set resource requests on package builds (#29922)Christopher Kotfila5-46/+465
gitlab ci: Set resource requests explicitly This PR sets resource requests for the Kubernetes executor, which should aid in better workload scheduling in the cluster. The specific values were derived from profile data taken from several full "from scratch" rebuilds in a separate worker pool. Co-authored-by: Zack Galbreath <zack.galbreath@kitware.com>
2022-04-14spack ci: remove relate-CDash-builds functionality (#29950)Zack Galbreath1-1/+1
gitlab ci: Remove code for relating CDash builds Relating CDash builds to their dependencies was a seldom used feature. Removing it will make it easier for us to reorganize our CDash projects & build groups in the future by eliminating the needs to keep track of CDash build ids in our binary mirrors.
2022-04-13Add support for Python 3.10 (#29581)Massimiliano Culpo4-0/+472
* Add support for Python 3.10 * Update unit-tests to use 3.10 * Update Getting started section of the docs * Update bootstrap action
2022-04-07Use the non-deprecated `MetaPathFinder` interface (#29745)Massimiliano Culpo1-0/+3
* Extract the MetaPathFinder and Loaders for packages in their own classes https://peps.python.org/pep-0451/ Currently, RepoPath and Repo implement the (deprecated) interface of MetaPathFinder (find_module) and of Loader (load_module). This commit extracts both of them and places the code in their own classes. The MetaPathFinder interface is updated to contain both the deprecated "find_module" (for Python 2.7 support) and the recommended "find_spec". Update of the Loader interface is deferred at a subsequent commit. * Move the lines to be prepended inside "RepoLoader" Also adjust the naming of a few variables too * Remove spack.util.imp, since code is only used in spack.repo * Remove support from loading Python modules Python > 3 but < 3.5 * Remove `Repo._create_namespace` This function was interacting badly with the MetaPathFinder and causing issues with "normal" imports. Removing the function allows to do things like: ```python import spack.pkg.builtin.mpich cls = spack.pkg.builtin.mpich.Mpich ``` * Remove code needed to trigger the Singleton evaluation The finder is coded in a way to trigger the Singleton, so we don't need external code now that we register it at module level into `sys.meta_path`. * Add unit tests
2022-04-07e4s ci: expand mac mini stack (#29929)eugeneswalker1-2/+2
2022-03-30spack ci: filter untouched pkgs from PR pipelines (#29697)Scott Wittenburg1-0/+1
We've previously generated CI pipelines for PRs, and they rebuild any packages that don't have a binary in an existing build cache. The assumption we were making was that ALL prior merged builds would be in cache, but due to the way we do security in the pipeline, they aren't. `develop` pipelines can take a while to catch up with the latest PRs, and while it does that, there may be a bunch of redundant builds on PRs that duplicate things being rebuilt on `develop`. Until we can do better caching of PR builds, we'll have this problem. We can do better in PRs, though, by *only* rebuilding things in the CI environment that are actually touched by the PR. This change computes exactly what packages are changed by a PR branch and *only* includes those packages' dependents and dependencies in the generated pipeline. Other as-yet unbuilt packages are pruned from CI for the PR. For `develop` pipelines, we still want to build everything to ensure that the stack works, and to ensure that `develop` catches up with PRs. This is especially true since we do not do rebuilds for *every* commit on `develop` -- just the most recent one after each `develop` pipeline finishes. Since we skip around, we may end up missing builds unless we ensure that we rebuild everything. We differentiate between `develop` and PR pipelines in `.gitlab-ci.yml` by setting `SPACK_PRUNE_UNTOUCHED` for PRs. `develop` will still have the old behavior. - [x] Add `SPACK_PRUNE_UNTOUCHED` variable to `spack ci` - [x] Refactor `spack pkg` command by moving historical package checking logic to `spack.repo` - [x] Implement pruning logic in `spack ci` to remove untouched packages - [x] add tests
2022-03-28spack info: make sections optional; add build/stand-alone test information ↵Tamara Dahlgren1-1/+1
(#22097) Add output of build- and install-time tests to info command Enable dependencies, variants, and versions by default (i.e., provide --no* options; add gcc to test_info_fields to increase coverage for c_names->v_names
2022-03-28e4s ci spack.yaml: add h5bench (#29755)eugeneswalker1-0/+1
2022-03-21e4s mini mac stack: add bzip2 (#29650)eugeneswalker1-0/+1
2022-03-19Revert "Add command for reading a json-based DB description (#24894)" (#29603)Nils Vu1-6/+2
This reverts commit 531b1c5c3dcc9bc7bec27e223608aed477e94dbd.
2022-03-18Add command for reading a json-based DB description (#24894)Peter Scheibel1-2/+6
Adds `spack external read-cray-manifest`, which reads a json file that describes a set of package DAGs. The parsed results are stored directly in the database. A user can see these installed specs with `spack find` (like any installed spec). The easiest way to use them right now as dependencies is to run `spack spec ... ^/hash-of-external-package`. Changes include: * `spack external read-cray-manifest --file <path/to/file>` will add all specs described in the file to Spack's installation DB and will also install described compilers to the compilers configuration (the expected format of the file is described in this PR as well including examples of the file) * Database records now may include an "origin" (the command added in this PR registers the origin as "external-db"). In the future, it is assumed users may want to be able to treat installs registered with this command differently (e.g. they may want to uninstall all specs added with this command) * Hash properties are now always preserved when copying specs if the source spec is concrete * I don't think the hashes of installed-and-concrete specs should change and this was the easiest way to handle that * also specs that are concrete preserve their `.normal` property when copied (external specs may mention compilers that are not registered, and without this change they would fail in `normalize` when calling `validate_or_raise`) * it might be this should only be the case if the spec was installed - [x] Improve testing - [x] Specifically mark DB records added with this command (so that users can do something like "uninstall all packages added with `spack read-external-db`) * This is now possible with `spack uninstall --all --origin=external-db` (this will remove all specs added from manifest files) - [x] Strip variants that are listed in json entries but don't actually exist for the package Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
2022-03-17Windows Support: Testing Suite integrationJohn Parent1-1/+1
Broaden support for execution of the test suite on Windows. General bug and review fixups
2022-03-17"spack commands --update-completion"John Parent1-1/+1
2022-03-17Add Github Actions for Windows (#24504)John Parent5-5/+41
Setup Installer CI (#25184), (#25191) Co-authored-by: Zack Galbreath <zack.galbreath@kitware.com> Co-authored-by: lou.lawrence@kitware.com <lou.lawrence@kitware.com> Co-authored-by: Betsy McPhail <betsy.mcphail@kitware.com>
2022-03-17Windows: Create installer and environmentlou.lawrence@kitware.com1-1/+10
* Add 'make-installer' command for Windows * Add '--bat' arg to env activate, env deactivate and unload commands * An equivalent script to setup-env on linux: spack_cmd.bat. This script has a wrapper to evaluate cd, load/unload, env activate/deactivate.(#21734) * Add spacktivate and config editor (#22049) * spack_cmd: will find python and spack on its own. It preferentially tries to use python on your PATH (#22414) * Ignore Windows python installer if found (#23134) * Bundle git in windows installer (#23597) * Add Windows section to Getting Started document (#23131), (#23295), (#24240) Co-authored-by: Stephen Crowell <stephen.crowell@kitware.com> Co-authored-by: lou.lawrence@kitware.com <lou.lawrence@kitware.com> Co-authored-by: Betsy McPhail <betsy.mcphail@kitware.com> Co-authored-by: Jared Popelar <jpopelar@txcorp.com> Co-authored-by: Ben Cowan <benc@txcorp.com> Update Installer CI Co-authored-by: John Parent <john.parent@kitware.com>
2022-03-14ci: add e4s mac stack (#29476)eugeneswalker2-0/+105
2022-03-09Fix tab completion erroring with `spack unit-test` (#29405)百地 希留耶2-5/+5
2022-03-08Fix overconstrained HDF5 variants (#29132)Seth R. Johnson1-2/+0
* hdf5: mark +fortran+shared conflict for older version This version was only activated unintentionally by silo's conflict statement, but `@1.8.15+shared+fortran+cxx` errors out in configure: ``` CMake Error at CMakeLists.txt:814 (message): **** Shared FORTRAN libraries are unsupported **** ``` * silo: refine hdf5 conflicts to avoid building old version Before this, `silo+hdf5` concretized to 1.10.7 or sometimes 1.8.15. Now I've verified it works for the following configurations: ``` silo@4.10.2 patches=7b5a1dc,952d3c9 ^ hdf5@1.10.7 api=default silo@4.10.2 patches=7b5a1dc,952d3c9,eb2a3a0 ^ hdf5@1.10.8 api=v18 silo@4.10.2 patches=7b5a1dc,952d3c9,eb2a3a0 ^ hdf5@1.12.1 api=v110 silo@4.11-bsd patches=eb2a3a0 ^ hdf5@1.12.1 api=v110 silo@4.11-bsd patches=eb2a3a0 ^ hdf5@1.10.8 api=default silo@4.11-bsd patches=eb2a3a0 ^ hdf5@1.12.1 api=default ``` and verified that the following fail: ``` silo@4.10.2 ^hdf5@1.12.1 api=default silo@4.11 ^hdf5 api=v18 silo@4.11-bsd ^hdf5@1.13.0 api=v12 silo@4.11-bsd ^hdf5@1.13.0 api=default ``` and have updated the constraints to match. Hdf5 no longer has to be downgraded to work with Silo. * silo: fix dependency conflicts * py-h5py: shorten and add comments to py-h5py hdf5 dependencies * e4s: remove slightly outdated hdf5 requirement * e4s: remove excessive hdf5 variant constraints These I think are holdovers from the old concretizer. - `hdf5_compat` can be expressed as `+hdf5 ^hdf5@1.8` - The extra variants on hdf5 shouldn't break conduit - axom unnecessarily restricts hdf5 version * conduit: restore hdf5_compat flag
2022-02-28Add a new test to catch exit code failure (#29244)Massimiliano Culpo1-0/+3
* Add a new test to catch exit code failure fixes #29226 This introduces a new unit test that checks the return code of `spack unit-test` when it is supposed to fail. This is to prevent bugs like the one introduced in #25601 in which CI didn't catch a missing return statement. In retrospective it seems that the shell test we have right now all go through `tty.die` or similar code paths which call `sys.exit(a)` explicitly. This new test instead checks `spack unit-test` which relies on the return code from command invocation in case of errors.
2022-02-22e4s ci: packages: prefer openturns@1.18 (#29154)eugeneswalker1-0/+2
2022-02-22Add `spack --bootstrap` option for accessing bootstrap store (#25601)Todd Gamblin1-1/+1
We can see what is in the bootstrap store with `spack find -b`, and you can clean it with `spack clean -b`, but we can't do much else with it, and if there are bootstrap issues they can be hard to debug. We already have `spack --mock`, which allows you to swap in the mock packages from the command line. This PR introduces `spack -b` / `spack --bootstrap`, which runs all of spack with `ensure_bootstrap_configuration()` set. This means that you can run `spack -b find`, `spack -b install`, `spack -b spec`, etc. to see what *would* happen with bootstrap configuration, to remove specific bootstrap packages, etc. This will hopefully make developers' lives easier as they deal with bootstrap packages. This PR also uses a `nullcontext` context manager. `nullcontext` has been implemented in several other places in Spack, and this PR consolidates them to `llnl.util.lang`, with a note that we can delete the function if we ever reqyire a new enough Python. - [x] introduce `spack --bootstrap` option - [x] consolidated all `nullcontext` usages to `llnl.util.lang`
2022-02-18spack external find: change default behavior (#29031)Massimiliano Culpo1-1/+1
See https://github.com/spack/spack/issues/25353#issuecomment-1041868116 This commit changes the default behavior of ``` $ spack external find ``` from searching all the possible packages Spack knows about to search only for the ones tagged as being a "build-tool". It also introduces a `--all` option to restore the old behavior.
2022-02-17Testing: optionally run tests on externally installed packages (#28701)Tamara Dahlgren1-1/+1
Since Spack does not install external packages, this commit skips them by default when running stand-alone tests. The assumption is that such packages have likely undergone an acceptance test process. However, the tests can be run against installed externals using ``` % spack test run --externals ... ```
2022-02-16commands: refactor `--reuse` handling to use configTodd Gamblin1-5/+5
`--reuse` was previously handled individually by each command that needed it. We are growing more concretization options, and they'll need their own section for commands that support them. Now there are two concretization options: * `--reuse`: Attempt to reuse packages from installs and buildcaches. * `--fresh`: Opposite of reuse -- traditional spack install. To handle thes, this PR adds a `ConfigSetAction` for `argparse`, so that you can write argparse code like this: ``` subgroup.add_argument( '--reuse', action=ConfigSetAction, dest="concretizer:reuse", const=True, default=None, help='reuse installed dependencies/buildcaches when possible' ) ``` With this, you don't need to add logic to pull the argument out and handle it; the `ConfigSetAction` just does it for you. This can probably be used to clean up some other commands later, as well. Code that was previously passing `reuse=True` around everywhere has been refactored to use config, and config is set from the CLI using a new `add_concretizer_args()` function in `spack.cmd.common.arguments`. - [x] Add `ConfigSetAction` to simplify concretizer config on the CLI - [x] Refactor code so that it does not pass `reuse=True` to every function. - [x] Refactor commands to use `add_concretizer_args()` and to pass concretizer config using the config system.
2022-02-10Stabilize the concretization of ecp-data-vis-sdk by preferring conduit@0.7.2 ↵Massimiliano Culpo1-0/+3
(#28871)
2022-02-10e4s: new specs: nccmp, nco, wannier90, lammps (#28833)eugeneswalker1-0/+4
2022-02-04e4s ci: uncomment variorum following pr #28754 (#28763)eugeneswalker2-2/+2
2022-02-02Revert "Deprecate Python 2 installations" (#28411)Adam J. Stewart1-0/+1
This reverts commit 7b76e3982f94ee952fe5d8fb0d19b389cc28228a.
2022-01-31e4s ci: add spec: gptune (#28604)eugeneswalker2-0/+2
2022-01-27Trilinos: minimize E4S CUDA build (#28591)Seth R. Johnson1-1/+3
* trilinos: update dependencies Use the tribits deps to clarify some dependencies, and group some together using `with` statements, eliminating some transitive conflict duplication. * trilinos: Restricit cuda incompatibility * e4s: vastly reduce number of packages in trilinos-cuda build Not clear who the customers of cuda-enabled trilinos are, or what options they need, or which sets of options conflict... * e4s: remove ~wrapper from trilinos+cuda
2022-01-14Update copyright year to 2022Todd Gamblin23-23/+23
2022-01-12commands: add `spack pkg source` and `spack pkg hash`Todd Gamblin1-1/+19
To make it easier to see how package hashes change and how they are computed, add two commands: * `spack pkg source <spec>`: dumps source code for a package to the terminal * `spack pkg source --canonical <spec>`: dumps canonicalized source code for a package to the terminal. It strips comments, directives, and known-unused multimethods from the package. It is used to generate package hashes. * `spack pkg hash <spec>`: This gives the package hash for a particular spec. It is generated from the canonical source code for the spec. - [x] `add spack pkg source` and `spack pkg hash` - [x] add tests - [x] fix bug in multimethod resolution with boolean `@when` values Co-authored-by: Greg Becker <becker33@llnl.gov>
2022-01-12Use depends_on over load in lmod module files generated by Spack (#28352)Harmen Stoppels1-6/+1
2022-01-12Remove tut since it requires deprecated Python 3.6 (#28360)Massimiliano Culpo1-1/+0
2022-01-06Fix spack install --v[tab] spec (#28278)Harmen Stoppels3-2/+12
2022-01-05llvm: make targets a multivalued variant (#27735)Harmen Stoppels2-2/+2
* llvm: make targets a multivalued variant * Fix the targets variant values 1. Make them lowercase and add a mapping to cmake equivalent 2. auto -> all 2. Restore composability by using a multivalued variant, so that `targets=all` and `targets=x86` is combined to `targets=all,x86` which is then transformed into LLVM_TARGETS_TO_BUILD=all. * use targets=x86 in iwyu * Default to nvptx/amdgpu/host arch targets * default to none * Update var/spack/repos/builtin/packages/zig/package.py
2021-12-23Merge tag 'v0.17.1' into developMassimiliano Culpo1-0/+2
2021-12-23New subcommand: spack bootstrap status (#28004)Massimiliano Culpo2-1/+6
This command pokes the environment, Python interpreter and bootstrap store to check if dependencies needed by Spack are available. If any are missing, it shows a comprehensible message.
2021-12-23Fix execution of style testsv0.17.1Massimiliano Culpo1-0/+2