Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

snapcraft "list-*" subcommands are inconsistent #4278

Open
rpjday opened this issue Jul 14, 2023 · 0 comments
Open

snapcraft "list-*" subcommands are inconsistent #4278

rpjday opened this issue Jul 14, 2023 · 0 comments
Labels
bug Actual bad behavior that don't fall into maintenance or documentation

Comments

@rpjday
Copy link
Contributor

rpjday commented Jul 14, 2023

Bug Description

snapcraft has a number of subcommands that come in pairs, of the form:

$ snapcraft fubar
$ snapcraft list-fubar

which mostly are consistent, but not totally. The variations I see are:

  • plugins
  • extensions
  • tracks
  • revisions
  • keys
  • validation-sets [sort of]

For the first four, if you run "snapcraft help list-fubar", the output, toward the end, refers the reader to the shorter form, but if you ask for help for the short form, you do not get referred to the longer form (a bit weird).

Next, it seems that the commands "list-keys" and "keys" are equivalent, but the "help" output for the two are entirely different; examine the output of each of:

$ snapcraft help list-keys
$ snapcraft help keys

to appreciate the strangeness.

Finally, for consistency, if there is a "list-validation-sets" subcommand, then there should be a "validation-sets" subcommand.

I can't think of a general rule for consistency for the above, but there should definitely be some consistency.

To Reproduce

Run the various "help" subcommands.

Environment

Ubuntu 22.04 amd64.

snapcraft.yaml

None.

Relevant log output

None.

Additional context

No response

@rpjday rpjday added the bug Actual bad behavior that don't fall into maintenance or documentation label Jul 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Actual bad behavior that don't fall into maintenance or documentation
Projects
None yet
Development

No branches or pull requests

1 participant