info: rework `spack info` command to display variants better by tgamblin · Pull Request #40998 · spack/spack

tgamblin · 2023-11-10T09:26:48Z

This pulls the spack info changes out of #40326 so they can go in before the full unified dictionary refactor.

Note that this does NOT fix #38302, but if you run spack info warpx you can clearly see the problem, as the information about the dims variant is lost. That will be fixed with #40326.

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of spack info.

Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width.

The new spack info looks like this (in an 80-col terminal):

This used to look like this in a 93-column terminal (left) and an 80=column terminal (right):

You can see that the 80-col version wraps horribly b/c we can't fit all the columns. This change also preserves any whitespace formatting present in package.py, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, gasnet has had a nice description of the conduits variant for a while, but it was wrapped and made illegible by spack info. That is now fixed and the original newlines are kept.

Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with --variants-by-name. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by when is the better default.

haampie · 2023-11-10T09:33:37Z

Looks pretty 🌈

I wonder if it can be slightly improved for boolean variants, cause it prints as

feature [true]                  false, true
build_system [cmake]            cmake, autotools

Maybe print default variant values in spec syntax

+name                           
build_system=cmake              cmake, autotools

but keep the bright color for the + and =cmake in the first column to indicate those are defaults?

tgamblin · 2023-11-10T09:35:23Z

Can we save that change for now? Not opposed but I think this is quite good already and want to get one more thing in if possible.

tgamblin · 2023-11-10T09:35:59Z

not 100% convinced that showing the default differently from the values is helpful but also like the +/~ so hmm.

haampie · 2023-11-10T09:38:08Z

The when clause headers already use spec syntax and refer to variants, so could be seen as consistent with that.

But yeah, if you wanna stress the name more than the value I get why you're doing name [value].

Anyways, big improvement 👍

tgamblin · 2023-11-10T09:39:32Z

I think stressing the name is better at least without further thought -- you run spack info to find out what variants there are first, values second.

tgamblin · 2023-11-10T09:42:03Z

I just got sick of running spack info on develop and having it show a garbly UI from the late 70's

haampie · 2023-11-10T09:43:16Z

True. Yet another alternative (for discussion, not a direct suggestion):

Highlight the default value only on the right-hand side to reduce the amount of information?

   build_type      Debug, RelWithDebInfo, [Release]
        CMake build type
   elpa            [false], true
        Use ELPA

tgamblin · 2023-11-10T09:44:00Z

I thought about that too but didn't like having to dig for the default on the RHS. For long lists it's hard to see what exactly the default is.

haampie · 2023-11-10T09:48:36Z

This is meant to be added to #40977?

Needs

spack commands --update-completion

tgamblin · 2023-11-10T09:48:55Z

yep please

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of `spack info`. Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width. This change also preserves any whitespace formatting present in `package.py`, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, `gasnet` has had a nice description of the `conduits` variant for a while, but it was wrapped and made illegible by `spack info`. That is now fixed and the original newlines are kept. Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with `--variants-by-name`. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by `when` is the better default.

Tests didn't cover the new `--variants-by-name` parameter in #40998. Add some parameterization to hit that. This changeset makes me think that the main section-printing loop in `spack info` isn't factored so well. It makes it difficult to pass different arguments to different helper functions. I could break it out into if statements if folks think that would be cleaner.

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of `spack info`. Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width. This change also preserves any whitespace formatting present in `package.py`, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, `gasnet` has had a nice description of the `conduits` variant for a while, but it was wrapped and made illegible by `spack info`. That is now fixed and the original newlines are kept. Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with `--variants-by-name`. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by `when` is the better default.

Tests didn't cover the new `--variants-by-name` parameter in #40998. Add some parameterization to hit that. This changeset makes me think that the main section-printing loop in `spack info` isn't factored so well. It makes it difficult to pass different arguments to different helper functions. I could break it out into if statements if folks think that would be cleaner.

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of `spack info`. Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width. This change also preserves any whitespace formatting present in `package.py`, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, `gasnet` has had a nice description of the `conduits` variant for a while, but it was wrapped and made illegible by `spack info`. That is now fixed and the original newlines are kept. Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with `--variants-by-name`. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by `when` is the better default.

Tests didn't cover the new `--variants-by-name` parameter in spack#40998. Add some parameterization to hit that. This changeset makes me think that the main section-printing loop in `spack info` isn't factored so well. It makes it difficult to pass different arguments to different helper functions. I could break it out into if statements if folks think that would be cleaner.

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of `spack info`. Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width. This change also preserves any whitespace formatting present in `package.py`, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, `gasnet` has had a nice description of the `conduits` variant for a while, but it was wrapped and made illegible by `spack info`. That is now fixed and the original newlines are kept. Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with `--variants-by-name`. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by `when` is the better default.

Tests didn't cover the new `--variants-by-name` parameter in spack#40998. Add some parameterization to hit that. This changeset makes me think that the main section-printing loop in `spack info` isn't factored so well. It makes it difficult to pass different arguments to different helper functions. I could break it out into if statements if folks think that would be cleaner.

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of `spack info`. Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width. This change also preserves any whitespace formatting present in `package.py`, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, `gasnet` has had a nice description of the `conduits` variant for a while, but it was wrapped and made illegible by `spack info`. That is now fixed and the original newlines are kept. Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with `--variants-by-name`. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by `when` is the better default.

Tests didn't cover the new `--variants-by-name` parameter in spack#40998. Add some parameterization to hit that. This changeset makes me think that the main section-printing loop in `spack info` isn't factored so well. It makes it difficult to pass different arguments to different helper functions. I could break it out into if statements if folks think that would be cleaner.

This changes variant display to use a much more legible format, and to use screen space much better (particularly on narrow terminals). It also adds color the variant display to match other parts of `spack info`. Descriptions and variant value lists that were frequently squished into a tiny column before now have closer to the full terminal width. This change also preserves any whitespace formatting present in `package.py`, so package maintainers can make easer-to-read descriptions of variant values if they want. For example, `gasnet` has had a nice description of the `conduits` variant for a while, but it was wrapped and made illegible by `spack info`. That is now fixed and the original newlines are kept. Conditional variants are grouped by their when clauses by default, but if you do not like the grouping, you can display all the variants in order with `--variants-by-name`. I'm not sure when people will prefer this, but it makes it easier to tell that a particular variant is/isn't there. I do think grouping by `when` is the better default.

spackbot-app bot added commands core PR affects Spack core functionality tests General test capability(ies) labels Nov 10, 2023

tgamblin requested review from alalazo and haampie November 10, 2023 09:31

tgamblin added the user-experience label Nov 10, 2023

haampie added this to the v0.21.0 milestone Nov 10, 2023

haampie mentioned this pull request Nov 10, 2023

Backports v0.21.0 (3) #40977

Merged

10 tasks

tgamblin force-pushed the new-spack-info branch from e25e9ce to 2c91968 Compare November 10, 2023 09:55

spackbot-app bot added the shell-support label Nov 10, 2023

haampie approved these changes Nov 10, 2023

View reviewed changes

haampie merged commit f0ced1a into develop Nov 10, 2023

haampie deleted the new-spack-info branch November 10, 2023 11:31

This was referenced Nov 10, 2023

info: improve coverage #41001

Merged

Unify directive dict structure #40326

Merged

Preserve line breaks in spack info output #23831

Closed

bonachea mentioned this pull request Dec 8, 2023

E4S-Documenter no longer correctly detects Accelerator Variants with new Spack E4S-Project/E4S-Documenter#8

Closed

masterleinad mentioned this pull request Apr 8, 2024

kokkos: enable +cuda_lambda by default for 4.0.00+ #38565

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

info: rework `spack info` command to display variants better#40998

info: rework `spack info` command to display variants better#40998
haampie merged 1 commit intodevelopfrom
new-spack-info

tgamblin commented Nov 10, 2023 •

edited

Loading

Uh oh!

haampie commented Nov 10, 2023 •

edited

Loading

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

haampie commented Nov 10, 2023 •

edited

Loading

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

haampie commented Nov 10, 2023 •

edited

Loading

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

haampie commented Nov 10, 2023 •

edited

Loading

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

tgamblin commented Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

haampie commented Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

haampie commented Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

haampie commented Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

haampie commented Nov 10, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin commented Nov 10, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tgamblin commented Nov 10, 2023 •

edited

Loading

haampie commented Nov 10, 2023 •

edited

Loading

haampie commented Nov 10, 2023 •

edited

Loading

haampie commented Nov 10, 2023 •

edited

Loading

haampie commented Nov 10, 2023 •

edited

Loading