`spack info`: show conditional dependencies and licenses; allow filtering by tgamblin · Pull Request #51137 · spack/spack

tgamblin · 2025-08-11T05:27:41Z

spack info has always shown dependencies grouped by type, but not conditional dependency information. While conditional deps are often very relevant, users have to read raw package files to see them.

This PR generifies the code used to display variants and uses it for dependencies and licenses too. As with variants, dependencies are shown grouped by conditions, with unconditional dependencies first. Users can supply the --by-name argument to list ordered first by name instead.

--by-name is meant to replace --variants-by-name. --variants-by-name still works but is suppressed from help and has the same function as --by-name.

spack info gcc before and after:

As there is increasingly more information displayed by spack info, it can be useful to filter out variants, dependencies, versions, etc. that are irrelevant to certain package configurations.

This PR also allows spack info to take a spec instead of a package name, so users can run, e.g.:

spack info [email protected]

to get only information relevant to 1.14.x versions of hdf5. Versions, dependencies, variants, and licenses are now filtered based on the input spec.

Before and after:

generify when-grouping code to use a Formatter class
Rewrite variant code to use generic formatter.
Rewrite dependency code to use generic formatter.
Rewrite license code to use generic formatter.
add full type annotations to cmd/info.py
allow spack info to take a spec instead of a package name
filter spack info output versions, dependencies, variants, and licenses based on the input spec
tests

alalazo

Overall this looks great. I think there is an issue with single-value variant. For instance check the dependencies of:

$ spack info zlib-ng build_system=autotools

vs.

$ spack info zlib-ng build_system:=autotools

Since build_system is multi=False specifying a value prevents other values to be possible.

Another issue is with conditional variants. For instance, in all CudaPackages, if we specify:

$ spack info trilinos~cuda

we continue to see pages of cuda_arch, even if that variant is gated on +cuda.

Finally, just a comment on colors (disregard this if you don't agree). I wouldn't use red for run dependencies, cause red is usually associated with failures. Maybe yellow?

I'll dive into code next.

alalazo

Minor comments, and two hints on the variant issues.

lib/spack/spack/package_base.py

lib/spack/spack/test/cmd/info.py

lib/spack/spack/cmd/info.py

haampie · 2025-08-28T06:14:25Z

Does this fix #51222?

tgamblin · 2025-08-28T21:16:55Z

I would say that it is in the spirit of #51222, in that it allows filtering by spec, but it doesn't exactly fix it b/c it doesn't address filtering by things like --phases or other metadata that's not on the spec.

I think a refactor towards something more general like --show versions,phases is in order (as there is a constantly growing number of sections). The current args are inconsistent as some of them are positive (--phases) and some of them are negative (--no-dependencies). I would rather just let the user say what they want.

tgamblin · 2025-09-29T00:59:09Z

@alalazo - I apparently wasn't in the loop with you and @haampie on the review of #35681, but in testing this I noticed that this code breaks the spack info filtering here for variant and dependency conditions that include versions, because spack.fetch_strategy.for_package_version() is actually modifying pkg.spec.

Does it have to do that? Can we not defensively copy in spack.fetch_strategy.for_package_version()? Why does it need to mutate the spec on the passed in package?

tgamblin · 2025-10-14T21:10:34Z

@alalazo: This PR is getting fairly large now but it's much improved. The commits are, I think, well factored into independent fixes/features now.

Fixing all the spec stuff above requires knowing something about the package. I was using Spec.intersects(), which says whether two constraints may coincide, but it knows too little about variants to do what you want, e.g., to know that a variant is only ever single-valued, or to know that the presence of a variant that's conditional on the value of some single-valued variant implies that no other values for that variant are allowable. I put in some static analysis in a new method on the Package to handle these cases, and it allows for much more aggressive filtering. e.g., if you ask for generator=make, it knows to rule out dependencies with build_system=autotools.
I added something that's maybe controversial -- if there are lots of deps, Spack now recommends getting rid of the bigger clumps of them by toggling certain variants at the end of spack info. I may remove this reminder later, but for now it's there to help with the many packages that use loops to set up locked cuda and/or rocm dependencies. I think this will ultimately be made much less necessary by Allow packages to depend on my.version, variant=my.value, etc. #41700, (where lots of rules will be reduced to something like `depends_on("dep cuda_arch={self.variants['cuda_arch'].value}"), but that is not ready yet.
I made text wrapping in spack info color-aware, which saves a space and avoids weird formatting.
I added some code to handle cases where the dependency spec is very long, e.g. some dependencies on boost have many variants. Instead of cramming the deptypes against the right margin, one letter per line, spack info now reserves 30 cols for the values in variant definitions, and it just puts them on the next line if the dep spec is too long.

See what you think and let me know if this is more usable.

This is a hack while we figure out why it's doing this Signed-off-by: Todd Gamblin <[email protected]>

`spack info` has always shown dependencies grouped by type, but not conditional dependency information. This generifies the code used to display variants and uses it for dependencies as well. As with variants, dependencies are shown grouped by conditions, with unconditional dependencies first. - [x] generify when-grouping code to use a `Formatter` class - [x] Rewrite variant code to use generic formatter. - [x] Rewrite dependency code to use generic formatter. - [x] add full type annotations to `cmd/info.py` Signed-off-by: Todd Gamblin <[email protected]>

Signed-off-by: Todd Gamblin <[email protected]>

`spack info` has historically accepted a package name but not a spec. Now that it shows lots of conditional information, it can be useful to filter out variants, dependencies, versions, etc. that are irrelevant to certain package configurations. - [x] allow `spack info` to take a spec instead of a package name - [x] filter `spack info` output versions, dependencies, variants, and licenses based on the input spec Signed-off-by: Todd Gamblin <[email protected]>

Signed-off-by: Todd Gamblin <[email protected]>

After adding dependencies, it is often much clearer to list info output by name, since there can be a very large number of dependency conditions in the output. `--by-when` is still an option, and the `--by-name` argument is still present even though it is the default. Signed-off-by: Todd Gamblin <[email protected]>

Signed-off-by: Todd Gamblin <[email protected]>

…itions This will advise users to add, e.g., `~cuda` and `~rocm` when output for a package is very long. This makes the feature more discoverable. Signed-off-by: Todd Gamblin <[email protected]>

Signed-off-by: Todd Gamblin <[email protected]>

For complex dependencies like boost, there may be many required variants. Ensure that they don't push deptypes off the edge of the screen by setting a min width and showing deptypes on the next line when the dependency spec is too long. Signed-off-by: Todd Gamblin <[email protected]>

- need to use long_spec for this Signed-off-by: Todd Gamblin <[email protected]>

Signed-off-by: Todd Gamblin <[email protected]>

tgamblin · 2025-10-17T06:19:08Z

Finally, just a comment on colors (disregard this if you don't agree). I wouldn't use red for run dependencies, cause red is usually associated with failures. Maybe yellow?

I went with blue and also fixed a couple bugs. This should be all done.

alalazo

The use cases pointed out in the previous review have been addressed 💯 Only minor comments that we can leave for a following PR.

lib/spack/spack/cmd/info.py

lib/spack/spack/test/cmd/info.py

lib/spack/spack/package_base.py

#51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]>

…51588) #51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]>

…pack#51588) spack#51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]>

…51588) #51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]>

…51588) #51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]>

…pack#51588) spack#51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]>

…51588) #51137 displays `when` conditions for dependencies, but it doesn't display direct or transitive dependencies in conditions. This is used frequently for things like * `when="^[email protected]:"`: optional deps for particular pythons * `when="%clang@34:"`: optional deps depending on build compiler - [x] change format for when from `Spec.format()` to `_long_spec()` - [x] add a test Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]>

tgamblin force-pushed the better-dependency-info branch 3 times, most recently from 3db9053 to 29dc0ea Compare August 14, 2025 08:01

alalazo self-assigned this Aug 14, 2025

alalazo self-requested a review August 14, 2025 16:48

alalazo reviewed Aug 15, 2025

View reviewed changes

alalazo requested changes Aug 15, 2025

View reviewed changes

lib/spack/spack/package_base.py Outdated Show resolved Hide resolved

lib/spack/spack/test/cmd/info.py Outdated Show resolved Hide resolved

lib/spack/spack/cmd/info.py Show resolved Hide resolved

lib/spack/spack/cmd/info.py Show resolved Hide resolved

alalazo added the user-experience label Aug 15, 2025

tgamblin mentioned this pull request Aug 29, 2025

spec: change default string representation of arch components #51246

Merged

tgamblin force-pushed the better-dependency-info branch 5 times, most recently from 4b79bce to 26cb54f Compare October 14, 2025 20:43

tgamblin requested a review from alalazo October 14, 2025 20:59

tgamblin force-pushed the better-dependency-info branch 6 times, most recently from 79df9eb to d8157f0 Compare October 16, 2025 02:14

fetch_strategy: for_package_version should not mutate pkg.spec

7cd0ab6

This is a hack while we figure out why it's doing this Signed-off-by: Todd Gamblin <[email protected]>

tgamblin force-pushed the better-dependency-info branch 2 times, most recently from 2de8ce1 to 179ada9 Compare October 17, 2025 06:02

tgamblin added 2 commits October 16, 2025 23:04

spack info: use when formatting for licenses

780f7d8

Signed-off-by: Todd Gamblin <[email protected]>

tgamblin added 10 commits October 16, 2025 23:04

Add PackageBase.intersects() to include more static information

959b677

Signed-off-by: Todd Gamblin <[email protected]>

spack info: fix error messages when 1 or 0 specs are provided

db9e928

Signed-off-by: Todd Gamblin <[email protected]>

spack info: validate variant names in input specs

6b4b694

Signed-off-by: Todd Gamblin <[email protected]>

spack info: suggest disabling variants when there are too many cond…

e7a8707

…itions This will advise users to add, e.g., `~cuda` and `~rocm` when output for a package is very long. This makes the feature more discoverable. Signed-off-by: Todd Gamblin <[email protected]>

spack info: make text wrapping in output color-aware

3b3c743

Signed-off-by: Todd Gamblin <[email protected]>

spack info: show compiler info in dependency specs

f9e246d

- need to use long_spec for this Signed-off-by: Todd Gamblin <[email protected]>

spack info: add more extensive testing for filtering

6b28358

Signed-off-by: Todd Gamblin <[email protected]>

tgamblin force-pushed the better-dependency-info branch from 179ada9 to 6b28358 Compare October 17, 2025 06:04

alalazo approved these changes Oct 19, 2025

View reviewed changes

tgamblin merged commit 20d4a0a into develop Oct 19, 2025
33 checks passed

tgamblin deleted the better-dependency-info branch October 19, 2025 21:48

tgamblin mentioned this pull request Oct 20, 2025

Fixups for spack info #51450

Merged

tgamblin added this to the v1.1.0 milestone Nov 14, 2025

tgamblin mentioned this pull request Nov 15, 2025

bugfix: display when conditions with dependencies in spack info #51588

Merged

2 tasks

becker33 mentioned this pull request Jan 10, 2026

Backports: v1.0.3 #51834

Merged

Conversation

tgamblin commented Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alalazo left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

haampie commented Aug 28, 2025

Uh oh!

tgamblin commented Aug 28, 2025

Uh oh!

tgamblin commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin commented Oct 14, 2025

Uh oh!

tgamblin commented Oct 17, 2025

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tgamblin commented Aug 11, 2025 •

edited

Loading

alalazo left a comment •

edited

Loading

tgamblin commented Sep 29, 2025 •

edited

Loading