maintenance/v0.23.0 fermi/fix duplication style #468
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…[email protected] (spack#47091) * r-textshaping: build-dep on pkgconfig to find harfbuzz * r-ragg: Fix build with [email protected]
* gaudi: gdb doesn't build on macos/arm64 * fix imports
This commit adds a new version of ACTS and detray.
This adds the current latest version of py-uv. While working on this, I also found that uv (including older versions) has a build dependency on cmake which was not specified in the package, so I added it as a dependency. I also found that on my machine, the build process had trouble finding cmake, so I set the path to it explicitly as an environment variable.
* Add a descriptor to have a class level constant This descriptor helps intercept places where we set a value on instances. It does not really behave like "const" in C-like languages, but is the simplest implementation that might still be useful. * Add a descriptor to deprecate properties/attributes of an object This descriptor is used as a base class. Derived classes may implement a factory to return an adaptor to the attribute being deprecated. The descriptor can either warn, or raise an error, when usage of the deprecated attribute is intercepted. --------- Co-authored-by: Harmen Stoppels <[email protected]>
* Added packages to for intel-2025.0.0 release * fix style * pin mkl to 2024.2.2 until e4s can upgrade to 2025 compiler and ginkgo compatibility issue can be resolved. --------- Co-authored-by: Robert Cohn <[email protected]>
Signed-off-by: Georgia Stuart <[email protected]>
and it installs.
* r-*: updates to latest versions * r-*: add new dependencies * r-proj: fix docstring line length * r-list: add homepage * r-*: add more dependencies * r-rmpi: use virtual dependencies, conflict openmpi@5: * r-cairo: require cairo +png; +pdf for some versions; cairo +fc when +ft * r-proj: set LD_LIBRARY_PATH since rpath not respected
This was caught by `codespell` when I copied the config file into an internal repository.
The problem was that `+` is part of the regex grammar, so it needs to be escaped.
Signed-off-by: Massimiliano Culpo <[email protected]>
The idea is that `spack -e env add ./concrete-spec.json` would list the full hash in the specs, so that (a) it's not ambiguous and (b) it could in principle results in constant time lookup instead of linear time substring match in large build caches.
SCR and the SCR components have new releases - AXL v0.9.0 - MPI variant added to AXL package - ER v0.5.0 - KVTREE v1.5.0 - Rankstr v0.4.0 - Shuffile v0.4.0 - Spatha v0.4.0 - dtcmp v1.1.5 - lwgrp v1.0.6 - Redset v0.4.0 - New variants added to Redset - SCR v3.1.0 - Added Flux resourse manager - Added pthreads variant - Removed deprecated release candidates and references - Cleaned up component dependency versions - Updated versions within variants and cleaned up cmake_args
Currently the order in which hooks are run is arbitrary. This can be fixed by sorted(list_modules(...)) but I think it is much more clear to just have a static list. Hooks are not extensible other than modifying Spack code, which means it's unlikely people maintain custom hooks since they'd have to fork Spack. And if they fork Spack, they might as well add an entry to the list when they're continuously rebasing.
* add verdict package Co-authored-by: becker33 <[email protected]> Co-authored-by: Alec Scott <[email protected]>
caught by `prettier`
* mpidiff: new package * fix style with black * Add variants, docs, and examples variants. Remove options that are not really options in the build.
…ack#47121) Co-authored-by: Bernhard Kaindl <[email protected]>
* py-constantly: added version 23.10.4 * py-constantly: fixed dependency on py-versioneer * py-constantly: updated py-versioneer dependency Co-authored-by: Tamara Dahlgren <[email protected]> --------- Co-authored-by: Tamara Dahlgren <[email protected]>
* xfsprogs: fix dependency on gettext * changed dependency on gettext in xfsprogs Co-authored-by: Wouter Deconinck <[email protected]> --------- Co-authored-by: Wouter Deconinck <[email protected]>
* parsec: update urls * parsec: fix homepage
* geomodel: Allow configuring C++ standard * drop c++11
We added unification semantics for parsing specs from the CLI, but there are a couple
of special cases in which we can avoid calls to the concretizer for speed when the
specs can all be resolved by lookups.
- [x] special case 1: solving a single spec
- [x] special case 2: all specs are either concrete (come from a file) or have an abstract
hash. In this case if concretizer:unify:true we need an additional check to confirm
the specs are compatible.
- [x] add a parameterized test for unifying on the CI
---------
Signed-off-by: Todd Gamblin <[email protected]>
Co-authored-by: Todd Gamblin <[email protected]>
Co-authored-by: sxs-bot <[email protected]>
…ages. (spack#46729) This PR provides complementary 2 features: 1. An augmentation to the package language to express ABI compatibility relationships among packages. 2. An extension to the concretizer that can synthesize splices between ABI compatible packages. 1. The `can_splice` directive and ABI compatibility We augment the package language with a single directive: `can_splice`. Here is an example of a package `Foo` exercising the `can_splice` directive: class Foo(Package): version("1.0") version("1.1") variant("compat", default=True) variant("json", default=False) variant("pic", default=False) can_splice("[email protected]", when="@1.1") can_splice("[email protected]", when="@1.0+compat") can_splice("[email protected]+compat", when="@1.0+compat", match_variants="*") can_splice("[email protected]", [email protected]~compat", match_variants="json") Explanations of the uses of each directive: - `can_splice("[email protected]", when="@1.1")`: If `[email protected]` is the dependency of an already installed spec and `[email protected]` could be a valid dependency for the parent spec, then `[email protected]` can be spliced in for `[email protected]` in the parent spec. - `can_splice("[email protected]", when="@1.0+compat")`: If `[email protected]` is the dependency of an already installed spec and `[email protected]+compat` could be a valid dependency for the parent spec, then `[email protected]+compat` can be spliced in for `[email protected]+compat` in the parent spec - `can_splice("[email protected]", when="@1.0+compat", match_variants="*")`: If `[email protected]+compat` is the dependency of an already installed spec and `[email protected]+compat` could be a valid dependency for the parent spec, then `[email protected]+compat` can be spliced in for `[email protected]+compat` in the parent spec, provided that they have the same value for all other variants (regardless of what those values are). - `can_splice("[email protected]", [email protected]~compat", match_variants="json")`:If `[email protected]` is the dependency of an already installed spec and `[email protected]~compat` could be a valid dependency for the parent spec, then `[email protected]~compat` can be spliced in for `[email protected]` in the parent spec, provided that they have the same value for their `json` variant. 2. Augmenting the solver to synthesize splices ### Changes to the hash encoding in `asp.py` Previously, when including concrete specs in the solve, they would have the following form: installed_hash("foo", "xxxyyy") imposed_constraint("xxxyyy", "foo", "attr1", ...) imposed_constraint("xxxyyy", "foo", "attr2", ...) % etc. Concrete specs now have the following form: installed_hash("foo", "xxxyyy") hash_attr("xxxyyy", "foo", "attr1", ...) hash_attr("xxxyyy", "foo", "attr2", ...) This transformation allows us to control which constraints are imposed when we select a hash, to facilitate the splicing of dependencies. 2.1 Compiling `can_splice` directives in `asp.py` Consider the concrete spec: [email protected]%[email protected] arch=linux-ubuntu22.04-icelake build_system=autotools ^bar ... It will emit the following facts for reuse (below is a subset) installed_hash("foo", "xxxyyy") hash_attr("xxxyyy", "hash", "foo", "xxxyyy") hash_attr("xxxyyy", "version", "foo", "2.72") hash_attr("xxxyyy", "node_os", "ubuntu22.04") hash_attr("xxxyyy", "hash", "bar", "zzzqqq") hash_attr("xxxyyy", "depends_on", "foo", "bar", "link") Rules that derive abi_splice_conditions_hold will be generated from use of the `can_splice` directive. They will have the following form: can_splice("[email protected]+a", when="@1.0.1+a", match_variants=["b"]) ---> abi_splice_conditions_hold(0, node(SID, "foo"), "foo", BaseHash) :- installed_hash("foo", BaseHash), attr("node", node(SID, SpliceName)), attr("node_version_satisfies", node(SID, "foo"), "1.0.1"), hash_attr("hash", "node_version_satisfies", "foo", "1.0.1"), attr("variant_value", node(SID, "foo"), "a", "True"), hash_attr("hash", "variant_value", "foo", "a", "True"), attr("variant_value", node(SID, "foo"), "b", VariVar0), hash_attr("hash", "variant_value", "foo", "b", VariVar0). 2.2 Synthesizing splices in `concretize.lp` and `splices.lp` The ASP solver generates "splice_at_hash" attrs to indicate that a particular node has a splice in one of its immediate dependencies. Splices can be introduced in the dependencies of concrete specs when `splices.lp` is conditionally loaded (based on the config option `concretizer:splice:True`. 2.3 Constructing spliced specs in `asp.py` The method `SpecBuilder._resolve_splices` implements a top-down memoized implementation of hybrid splicing. This is an optimization over the more general `Spec.splice`, since the solver gives a global view of exactly which specs can be shared, to ensure the minimal number of splicing operations. Misc changes to facilitate configuration and benchmarking - Added the method `Solver.solve_with_stats` to expose timers from the public interface for easier benchmarking - Added the boolean config option `concretizer:splice` to conditionally load splicing behavior Co-authored-by: Greg Becker <[email protected]>
…pack#47567) benchmarked to test if that is a correct decision.
`spack spec` output has looked like this for a while: ```console > spack spec /v5fn6xo /wd2p2v7 Input spec -------------------------------- - /v5fn6xo Concretized -------------------------------- [+] [email protected]%[email protected]~docs+shared build_system=generic certs=mozilla arch=darwin-sequoia-m1 [+] ^ca-certificates-mozilla@2023-05-30%[email protected] build_system=generic arch=darwin-sequoia-m1 ... Input spec -------------------------------- - /wd2p2v7 Concretized -------------------------------- [+] [email protected]%[email protected] build_system=python_pip arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=generic arch=darwin-sequoia-m1 ``` But the input spec is right there on the CLI, and it doesn't add anything to the output. Also, since spack#44843, specs concretized in the CLI line can be unified, so it makes sense to display them as we did in spack#44489 -- as one multi-root tree instead of as multiple single-root trees. With this PR, concretize output now looks like this: ```console > spack spec /v5fn6xo /wd2p2v7 [+] [email protected]%[email protected]~docs+shared build_system=generic certs=mozilla arch=darwin-sequoia-m1 [+] ^ca-certificates-mozilla@2023-05-30%[email protected] build_system=generic arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected]~guile build_system=generic arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected]+cpanm+opcode+open+shared+threads build_system=generic arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected]+cxx~docs+stl build_system=autotools patches=26090f4,b231fcc arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected]~debug~pic+shared build_system=generic arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=autotools arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=autotools libs=shared,static arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=autotools arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=autotools patches=bbf97f1 arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected]~symlinks+termlib abi=none build_system=autotools patches=7a351bc arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=autotools arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected]+compat+new_strategies+opt+pic+shared build_system=autotools arch=darwin-sequoia-m1 [+] ^gnuconfig@2022-09-17%[email protected] build_system=generic arch=darwin-sequoia-m1 [+] [email protected]%[email protected] build_system=python_pip arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=generic arch=darwin-sequoia-m1 [+] ^[email protected]%[email protected] build_system=generic arch=darwin-sequoia-m1 [-] ^[email protected]%[email protected] build_system=generic arch=darwin-sequoia-m1 ... ``` With no input spec displayed -- just the concretization output shown as one consolidated tree and multiple roots. - [x] remove "Input Spec" section and "Concretized" header from `spack spec` output - [x] print concretized specs as one BFS tree instead of multiple --------- Signed-off-by: Todd Gamblin <[email protected]> Co-authored-by: Harmen Stoppels <[email protected]>
Automatic splicing say `Spec` grow a `__len__` method but it's only used
in one place and it's not clear the semantics are useful elsewhere. It also
runs the risk of Specs one day being confused for other types of containers.
Rather than introduce a new function for one algorithm, let's use a more
specific method in the splice code.
- [x] Use topological ordering in `_resolve_automatic_splices` instead of
sorting by node count
- [x] delete `Spec.__len__()` and `Spec.__bool__()`
---------
Signed-off-by: Todd Gamblin <[email protected]>
Co-authored-by: Greg Becker <[email protected]>
Co-authored-by: Massimiliano Culpo <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
caliper: add+pythonvariant withpybind11bindings (caliper: add+pythonvariant withpybind11bindings spack/spack#47031)damask(damask-mesh,damask-grid,py-damask): Add new version 3.0.1 spack/spack#47093)spack find -u(Fix brokenspack find -uspack/spack#47102)infernal: add version1.1.5(infernal: add version1.1.5spack/spack#47028)functools.partial(mypy: work around typing issues withfunctools.partialspack/spack#47160)papi(extrae: actually makepapian optional dependency spack/spack#47179)Database.query*methods (ImproveDatabase.query*methods spack/spack#47116)-tshort option forspack --backtrace(Add-tshort option forspack --backtracespack/spack#47227)develop-X.Ybranch versions spack/spack#39344)concretizer.yaml(Fix typo in defaultconcretizer.yamlspack/spack#47307)spack audit externals(Fix errors found by runningspack audit externalsspack/spack#47308)==equality (Specs: propagated variants affect==equality spack/spack#47376)cc: simplify ordered list handlingldmodemax_depthargument tofind(Improve lib search functionality spack/spack#41945)spack -c <override>when env active (Fixspack -c <override>when env active spack/spack#47403)llnl.util.filesystem.find: multiple entrypoints (llnl.util.filesystem.find: multiple entrypoints spack/spack#47436)llnl.util.filesystem.find: multiple entrypoints (llnl.util.filesystem.find: multiple entrypoints spack/spack#47436)"max_depthargument tofind(Improve lib search functionality spack/spack#41945)"spack env trackcommand (spack env trackcommand spack/spack#41897)**spack.compiler/spack.util.libc: add caching (spack.compiler/spack.util.libc: add caching spack/spack#47213)conditionaltodirectives.pyspack find -xin environments (Bugfix:spack find -xin environments spack/spack#46798)diamond,py-alive-progress,py-bakta,py-deepsig-biocomp), new packages (py-pyhmmer,py-pyrodigal) (packages: new versions (diamond,py-alive-progress,py-bakta,py-deepsig-biocomp), new packages (py-pyhmmer,py-pyrodigal) spack/spack#47277)spack spec: simplify and unify output (spack spec: simplify and unify output spack/spack#47574)__len__(Spec: prefer a splice-specific method to__len__spack/spack#47585)