netcdf-fortran@4.5: will error if netcdf-c has been built with MPI
support:
```
configure: error:
-----------------------------------------------------------------------
The NetCDF C library is built with parallel I/O feature enabled, but
the Fortran compiler '.../lib/spack/env/gcc/gfortran' supplied in this configure command
does not support MPI-IO. Please use one that does. If parallel I/O
feature is not desired, please use a NetCDF C library with parallel
I/O feature disabled. Abort.
-----------------------------------------------------------------------
```
Copy logic from netcdf-c to add an `mpi` variant.
* pybind11: test get_include path
Helper for non-CMake downstream projects to find the pybind11
header location.
* pybind11: return proper get_include()
use our prefix instead of letting pybind11 trying to self-determine
it from given conda/virtualenv/global rules.
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* new package: py-ics
* drop 0.5 and move to tar-ball
* Update var/spack/repos/builtin/packages/py-ics/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-ics/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* mpi4py 3.0.3
Adds support for Python 3.8 with new Cython files.
I tried to build 3.0.0 with Python 3.8 and this builds as well,
therefor I added no conflict.
* mpi4py: update dependency version ranges
* update py-jupyter-notebook
* add setuptools dependency for newer version
the whole jupyter collection seems to use setuptools in case of
certain setup.py-arguments from the very beginning. However the latest
ones actually require it, otherwise the build will fail
* add newly introduced dependencies
* dependency constraints
* drop terminal variant and update python dep
* added relion 3.0.8 [latest stable version in 3.0 branch] as well as 3.1_beta
* relion 3.1 beta compiles without Benchmarking build type see https://github.com/3dem/relion/issues/533
* relion 3.0.X - 3.1 now supports latest cmake@3
This fixes a regression introduced in #10792. `spack uninstall` in an
environment would not match concrete query specs properly after the index
hash of enviroments changed.
- [x] Search by DAG hash for specs to remove instead of by build hash
If you do this in a spack environment:
spack add hdf5+hl
hdf5+hl will be the root added to the `spack.yaml` file, and you should
really expect `hdf5+hl` to display as a root in the environment.
- [x] Add decoration to roots so that you can see the details about what
is required to build.
- [x] Add a test.
* flux: add `url_for_version` to support their C4 repo model
Flux uses a fork of ZeroMQ's Collective Code Construction Contract
(https://github.com/flux-framework/rfc/blob/master/spec_1.adoc).
This model requires a repository fork for every stable release that has
patch releases. For example, 0.8.0 and 0.9.0 are both tags within the
main repository, but 0.8.1 and 0.9.5 would be releases on the v0.8 and
v0.9 forks, respectively.
* flux: add latest versions
* flux: remove master from `when=@0.X:,master` statements
Now that #1983 has been merged, master > 0.X.0.
* flux-core: remove extraneous `99` patch version in `when` range
Replace `when=@:0.11.99` with `when=@:0.11` since the intention is to
include all patch versions of `0.11`.
* flux-core: fix `setup_build_environment` after changes in #13411
In #13411, `setup_environment` was split into `setup_build_environment`
and `setup_run_environment`, with the `spack_env` and `run_env`
arguments being changed to `env`. Somehow the flux package was the only
one to not have its `spack_env` references in the function changed to
`env`.
* flux: add runtime environment variables that Flux checks
with older versions of Flux (i.e, 0.0:0.13), FLUX_CONNECTOR_PATH must be
set by spack to prevent failures in certain
scenarios (https://github.com/flux-framework/flux-core/issues/2456).
the flux binary also sets some other environment variables, which can be
listed by running `flux -v start`. I added a few of those just to be
sure that the Spack-installed paths are used, rather than
system-installed ones.
* flux: add optional testing dependencies to maximize test coverage
Install optional dependencies to ensure that only spack-installed
software is detected and that all tests are run when `spack install
--test` is used.
Flux's test suite will test for the existance of valgrind, jq, and any
MPI installation. If it detects them (even if they are system-installed
and outside the spack environment), it will run optional tests against
them. I noticed on my machine that the valgrind tests were running
against the system-install valgrind.
* flux-sched: switch to new `setup_run_environment` API
- [x] insert at beginning of list so fetch grabs local mirrors before remote resources
- [x] update the S3FetchStrategy so that it throws a SpackError if the fetch fails.
Before, it was throwing URLError, which was not being caught in stage.py.
- [x] move error handling out of S3FetchStrategy and into web_util.read_from_url()
- [x] pass string instead of URLError to SpackWebError
* r-gstat: new package at 2.0-3
* Update var/spack/repos/builtin/packages/r-gstat/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/r-gstat/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
This changes Spack environments so that the YAML file associated with the environment is *only* written when necessary (i.e., if it is changed *by spack*). The lockfile is still written out as before.
There is a larger question here of which part of Spack should be responsible for setting defaults in config files, and how we can get rid of empty lists and data structures currently cluttering files like `compilers.yaml`. But that probably requires a rework of the default-setting validator in `spack.config`, as well as the code that uses `spack.config`. This will at least help for `spack.yaml`.
* Improvements of saga-gis package
* Added explicit version ranges for old saga-gis version
* Update var/spack/repos/builtin/packages/saga-gis/package.py
Creative usage of redefinition of getter method
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/saga-gis/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/saga-gis/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
