summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-20[add] py-fraction: new package (#40554)Lydéric Debusschère1-0/+22
Co-authored-by: LydDeb <lyderic.debusschere@eolen.com>
2023-10-20[add] py-cssutils: new package (#40551)Lydéric Debusschère1-0/+21
Co-authored-by: LydDeb <lyderic.debusschere@eolen.com>
2023-10-20[add] py-css-parser: new package (#40550)Lydéric Debusschère1-0/+19
Co-authored-by: LydDeb <lyderic.debusschere@eolen.com>
2023-10-20py-statsmodels: add 0.14.0 (#39156)Manuela Kuhn1-23/+32
* py-statsmodels: add 0.14.0 * Fix style * Update var/spack/repos/builtin/packages/py-statsmodels/package.py Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com> * Update var/spack/repos/builtin/packages/py-statsmodels/package.py Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com> * Remove python limits * Remove comment --------- Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2023-10-20py-dcm2bids: add v3.1.0 (#40447)Manuela Kuhn1-3/+7
* py-dcm2bids: add 3.1.0 * Fix python restriction
2023-10-20py-bidscoin: add v4.1.1 and py-argparse-manpage: add new package (#40414)Manuela Kuhn2-4/+35
* py-bidscoin: add 4.1.1 * Fix style * Fix restrictions for dependencies
2023-10-20Add package py-macs3 and dependencies (#40498)snehring3-0/+74
* py-cykhash: adding new package py-cykhash * py-hmmlearn: adding new package py-hmmlearn * py-macs3: adding new package py-macs3 * py-macs3: adding python version restriction and other changes.
2023-10-20schema/compilers.py: fix validation of 2+ entries (#40627)Harmen Stoppels1-54/+52
Fix the following syntax which validates only the first array entry: ```python "compilers": { "type": "array", "items": [ { "type": ... } ] } ``` to ```python "compilers": { "type": "array", "items": { "type": ... } } ``` which validates the entire array. Oops...
2023-10-20Drop support for external PythonX.Y (#40628)Adam J. Stewart1-1/+1
On some systems, multiple pythonx.y are placed in the same prefix as pythonx (where only one of them is associated with that pythonx). Spack external detection for Python was willing to register all of these as external versions. Moreover, the `package.py` for Python was able to distinguish these. This can cause an issue for some build systems, which will just look for python3 for example, so if that python3 is actually python3.6, and the build system needs 3.7 (which spack may have found in the same prefix, and offered as a suitable external), it will fail when invoking python3. To avoid that issue, we simply avoid treating pythonx.y as external candidates. In the above case, Spack would only detect a Python 3.6 external, and the build would be forced to use a Spack-built Python 3.7 (which we consider a good thing).
2023-10-19TAU: Respect ~fortran for +mpi (#40617)wspear1-2/+3
2023-10-19vtk-m: update to latest release (#40624)Vicente Bolea1-1/+1
2023-10-20perl: change permissions in order to apply patch on version 5.38.0 (#40609)Lydéric Debusschère1-4/+16
Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
2023-10-19build(deps): bump actions/checkout from 4.1.0 to 4.1.1 (#40584)dependabot[bot]8-26/+26
2023-10-19build(deps): bump mypy from 1.6.0 to 1.6.1 in /lib/spack/docs (#40603)dependabot[bot]1-1/+1
2023-10-19build(deps): bump mypy from 1.6.0 to 1.6.1 in /.github/workflows/style (#40602)dependabot[bot]1-1/+1
2023-10-19build(deps): bump urllib3 from 2.0.6 to 2.0.7 in /lib/spack/docs (#40583)dependabot[bot]1-1/+1
2023-10-19py-rasterio: add v1.3.9 (#40621)Adam J. Stewart1-0/+2
2023-10-19add nvechip to sundials components when mfem+rocm (#40512)Cody Balos1-0/+2
2023-10-19Improve setup build / run / test environment (#35737)Harmen Stoppels22-416/+565
This adds a `SetupContext` class which is responsible for setting package.py module globals, and computing the changes to environment variables for the build, test or run context. The class uses `effective_deptypes` which takes a list of specs (e.g. single item of a spec to build, or a list of environment roots) and a context (build, run, test), and outputs a flat list of specs that affect the environment together with a flag in what way they do so. This list is topologically ordered from root to leaf, so that one can be assured that dependents override variables set by dependencies, not the other way around. This is used to replace the logic in `modifications_from_dependencies`, which has several issues: missing calls to `setup_run_environment`, and the order in which operations are applied. Further, it should improve performance a bit in certain cases, since `effective_deptypes` run in O(v + e) time, whereas `spack env activate` currently can take up to O(v^2 + e) time due to loops over roots. Each edge in the DAG is visited once by calling `effective_deptypes` with `env.concrete_roots()`. By marking and propagating flags through the DAG, this commit also fixes a bug where Spack wouldn't call `setup_run_environment` for runtime dependencies of link dependencies. And this PR ensures that Spack correctly sets up the runtime environment of direct build dependencies. Regarding test dependencies: in a build context they are are build-time test deps, whereas in a test context they are install-time test deps. Since there are no means to distinguish the build/install type test deps, they're both. Further changes: - all `package.py` module globals are guaranteed to be set before any of the `setup_(dependent)_(run|build)_env` functions is called - traversal order during setup: first the group of externals, then the group of non-externals, with specs in each group traversed topological (dependencies are setup before dependents) - modules: only ever call `setup_dependent_run_environment` of *direct* link/run type deps - the marker in `set_module_variables_for_package` is dropped, since we should call the method once per spec. This allows us to set only a cheap subset of globals on the module: for example it's not necessary to compute the expensive `cmake_args` and w/e if the spec under consideration is not the root node to be built. - `spack load`'s `--only` is deprecated (it has no effect now), and `spack load x` now means: do everything that's required for `x` to work at runtime, which requires runtime deps to be setup -- just like `spack env activate`. - `spack load` no longer loads build deps (of build deps) ... - `spack env activate` on partially installed or broken environments: this is all or nothing now. If some spec errors during setup of its runtime env, you'll only get the unconditional variables + a warning that says the runtime changes for specs couldn't be applied. - Remove traversal in upward direction from `setup_dependent_*` in packages. Upward traversal may iterate to specs that aren't children of the roots (e.g. zlib / python have hundreds of dependents, only a small fraction is reachable from the roots. Packages should only modify the direct dependent they receive as an argument)
2023-10-19spack checksum: restore ability to select top n (#40531)Harmen Stoppels2-6/+40
The ability to select the top N versions got removed in the checksum overhaul, cause initially numbers were used for commands. Now that we settled on characters for commands, let's make numbers pick the top N again.
2023-10-19Automated deployment to update package flux-core 2023-10-19 (#40605)Vanessasaurus1-0/+1
Co-authored-by: github-actions <github-actions@users.noreply.github.com>
2023-10-19libvorbis: drop -force_cpusubtype_ALL flag (#40616)Harmen Stoppels1-0/+3
This flag was only relevant when targeting powerpc from apple-clang, which we don't do. The flag is removed from apple-clang@15. Let's drop it unconditionally.
2023-10-19gitlab ci: Rework how mirrors are configured (#39939)Scott Wittenburg36-150/+273
Improve how mirrors are used in gitlab ci, where we have until now thought of them as only a string. By configuring ci mirrors ahead of time using the proposed mirror templates, and by taking advantage of the expressiveness that spack now has for mirrors, this PR will allow us to easily switch the protocol/url we use for fetching binary dependencies. This change also deprecates some gitlab functionality and marks it for removal in Spack 0.23: - arguments to "spack ci generate": * --buildcache-destination * --copy-to - gitlab configuration options: * enable-artifacts-buildcache * temporary-storage-url-prefix
2023-10-19petsc: add variant +sycl (#40562)Satish Balay1-0/+16
* petsc: add variant +sycl * petsc: add in gmake as dependency - so that consistent make gets used between petsc and slepc builds [that can have different env for each of the builds]
2023-10-19ci: remove incorrect compilers.yaml (#40610)Harmen Stoppels1-27/+0
2023-10-19ASP-based solver: single Spec instance per dag hash (#39590)Massimiliano Culpo2-32/+127
Reused specs used to be referenced directly into the built spec. This might cause issues like in issue 39570 where two objects in memory represent the same node, because two reused specs were loaded from different sources but referred to the same spec by DAG hash. The issue is solved by copying concrete specs to a dictionary keyed by dag hash.
2023-10-19Stand-alone test feature deprecation postponed to v0.22 (#40600)Tamara Dahlgren1-2/+2
2023-10-19byte-unixbench: respect compiler choice (#39242)Aiden Grossman1-0/+4
Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
2023-10-19connect-proxy: respect compiler choice (#39243)Aiden Grossman1-0/+3
2023-10-19bioawk: respect compiler choice (#39241)Aiden Grossman1-0/+3
2023-10-19busybox: respect compiler choice (#39239)Aiden Grossman1-2/+2
2023-10-19julia: Fix build for @1.9 (#39045)Michael Kuhn1-0/+2
julia@1.9 tries to download ittapi, which requires cmake. Disable it explicitly.
2023-10-18acfl: add version 23.10 (#40510)Annop Wongwathanarat1-1/+35
2023-10-18unparse: also support generic type aliases (#40328)Harmen Stoppels1-0/+4
2023-10-18AutotoolsPackage / MakefilePackage: add gmake build dependency (#40380)Harmen Stoppels13-86/+133
2023-10-18llvm: fix ncurses+termlib linking in lldb (#40594)Harmen Stoppels1-0/+10
2023-10-18Fix dev-build keep_stage behavior (#40576)Harmen Stoppels2-52/+29
`spack dev-build` would incorrectly set `keep_stage=True` for the entire DAG, including for non-dev specs, even though the dev specs have a DIYStage which never deletes sources.
2023-10-18[fix] py-werkzeug: add constraint in python dependence (#40590)Lydéric Debusschère1-0/+1
py-werkzeug@:0.12 does not work with python@3.10: Test with py-werkzeug 0.12.2 and python 3.10: ``` $ python3.10 -c 'import werkzeug' py-werkzeug-0.12.2/lib/python3.11/site-packages/werkzeug/datastructures.py", line 16, in <module> from collections import Container, Iterable, MutableSet ImportError: cannot import name 'Container' from 'collections' ``` Test with py-werkzeug 0.12.2 and python 3.9: ``` python3.9 -c "from collections import Container" <string>:1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.10 it will stop working ```
2023-10-18Add license directive (#39346)Aiden Grossman9-0/+154
This patch adds in a license directive to get the ball rolling on adding in license information about packages to spack. I'm primarily interested in just adding license into spack, but this would also help with other efforts that people are interested in such as adding license information to the ASP solve for concretization to make sure licenses are compatible. Usage: Specifying the specific license that a package is released under in a project's `package.py` is good practice. To specify a license, find the SPDX identifier for a project and then add it using the license directive: ```python license("<SPDX Identifier HERE>") ``` For example, for Apache 2.0, you might write: ```python license("Apache-2.0") ``` Note that specifying a license without a when clause makes it apply to all versions and variants of the package, which might not actually be the case. For example, a project might have switched licenses at some point or have certain build configurations that include files that are licensed differently. To account for this, you can specify when licenses should be applied. For example, to specify that a specific license identifier should only apply to versionup to and including 1.5, you could write the following directive: ```python license("MIT", when="@:1.5") ```
2023-10-18abi.py: fix typo, add type-hints (#38216)Greg Becker2-13/+20
Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
2023-10-17paraview: add variant for NVIDIA IndeX (#40577)jfavre1-0/+4
* add variant for NVIDIA IndeX * remove whitespaces
2023-10-17xmlto: add more dependencies (#40578)Dennis Klein1-1/+14
`xmllint` is called by `xmlto` during generation of `libzmq`'s docs, so adding `libxml2`. The docbook deps and the patches are taken from https://src.fedoraproject.org/rpms/xmlto/blob/rawhide/f/xmlto.spec There are still many more dependencies missing, but this is out of scope of this patch (which is only concerned about the use case of `libzmq`).
2023-10-17Add tracy 0.10 (#40573)Mikael Simberg2-0/+2
2023-10-17Allow / in GitVersion (#39398)Peter Scheibel16-27/+214
This commit allows version specifiers to refer to git branches that contain forward slashes. For example, the following is valid syntax now: pkg@git.releases/1.0 It also adds a new method `Spec.format_path(fmt)` which is like `Spec.format`, but also maps unsafe characters to `_` after interpolation. The difference is as follows: >>> Spec("pkg@git.releases/1.0").format("{name}/{version}") 'pkg/git.releases/1.0' >>> Spec("pkg@git.releases/1.0").format_path("{name}/{version}") 'pkg/git.releases_1.0' The `format_path` method is used in all projections. Notice that this method also maps `=` to `_` >>> Spec("pkg@git.main=1.0").format_path("{name}/{version}") 'pkg/git.main_1.0' which should avoid syntax issues when `Spec.prefix` is literally copied into a Makefile as sometimes happens in AutotoolsPackage or MakefilePackage
2023-10-17Add mpi_f08 variant to CP2K (#40574)Rocco Meli1-0/+9
* add mpi_f08 variant * add conflict * add conflict with released versions of cp2k and +mpi_f08
2023-10-17py-rtree: add v1.1.0 (#40575)Adam J. Stewart1-2/+3
2023-10-17hiop: 1.0.1 release (#40580)Cameron Rutherford1-0/+1
2023-10-17patchelf: fix compilation with GCC 7 (#40581)Harmen Stoppels2-0/+28
2023-10-17Support apple-clang in pdt (#40582)wspear1-2/+2
2023-10-17Support `spack env activate --with-view <name> <env>` (#40549)Harmen Stoppels7-75/+120
Currently `spack env activate --with-view` exists, but is a no-op. So, it is not too much of a breaking change to make this redundant flag accept a value `spack env activate --with-view <name>` which activates a particular view by name. The view name is stored in `SPACK_ENV_VIEW`. This also fixes an issue where deactivating a view that was activated with `--without-view` possibly removes entries from PATH, since now we keep track of whether the default view was "enabled" or not.