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

The command name should default to CARGO_BIN_NAME #5738

Open
2 tasks done
ia0 opened this issue Sep 20, 2024 · 2 comments
Open
2 tasks done

The command name should default to CARGO_BIN_NAME #5738

ia0 opened this issue Sep 20, 2024 · 2 comments
Labels
A-derive Area: #[derive]` macro API C-enhancement Category: Raise on the bar on expectations M-breaking-change Meta: Implementing or merging this will introduce a breaking change. S-waiting-on-decision Status: Waiting on a go/no-go before implementing
Milestone

Comments

@ia0
Copy link

ia0 commented Sep 20, 2024

Please complete the following tasks

Clap Version

4.5.9

Describe your use case

I want the default -V / --version to use the binary name instead of the package name, because this is the name users are familiar with. This situation happens when a project has both a library and a CLI. The CLI usually provides a binary with a different name than the package.

The documentation says that the magic command attribute name defaults to the package name on Parser. I wonder if this was decided before CARGO_BIN_NAME was a thing, or if it's just an oversight, or if there is a good reason to do so.

Describe the solution you'd like

I'd like the default name to be CARGO_BIN_NAME instead of CARGO_PKG_NAME.

Alternatives, if applicable

The obvious workaround is to specify a command name. This is completely fine, but the default is in my opinion wrong, so I'm creating an issue to understand the rationale.

Additional Context

No response

@ia0 ia0 added the C-enhancement Category: Raise on the bar on expectations label Sep 20, 2024
ia0 added a commit to ia0/magika that referenced this issue Sep 20, 2024
The default is the package name which is `magika-cli`. We want to use the binary name which is
`magika`. Feature request on `clap` side: clap-rs/clap#5738.
ia0 added a commit to google/magika that referenced this issue Sep 20, 2024
The default is the package name which is `magika-cli`. We want to use the binary name which is
`magika`. Feature request on `clap` side: clap-rs/clap#5738.
@epage epage added M-breaking-change Meta: Implementing or merging this will introduce a breaking change. A-derive Area: #[derive]` macro API S-waiting-on-decision Status: Waiting on a go/no-go before implementing labels Sep 20, 2024
@epage epage added this to the 5.0 milestone Sep 20, 2024
@epage
Copy link
Member

epage commented Sep 20, 2024

Note that this would be a breaking change and wouild have to wait until clap v5, at least.

It would be good to sample various clap projects to see how package.name and bin.name might vary between them to see if there would be any unintended affect.

@ia0
Copy link
Author

ia0 commented Sep 20, 2024

Note that this would be a breaking change and wouild have to wait until clap v5, at least.

Yes, makes sense.

It would be good to sample various clap projects to see how package.name and bin.name might vary between them to see if there would be any unintended affect.

Yes, I'm also curious. I quickly looked at the top 20 reverse dependencies of clap and used the new "Install" feature of crates.io to identify those with a binary and the name of the binary too:

package binary notes
addr2line addr2line
remove_dir_all remove-dir-all for some reason, --version shows the binary name
cbindgen cbindgen
raw-cpuid cpuid affected by this issue, see gz/rust-cpuid#189
dotenvy dotenvy
dotenv dotenv

So it seems to not affect that many crates on such a small sample.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-derive Area: #[derive]` macro API C-enhancement Category: Raise on the bar on expectations M-breaking-change Meta: Implementing or merging this will introduce a breaking change. S-waiting-on-decision Status: Waiting on a go/no-go before implementing
Projects
None yet
Development

No branches or pull requests

2 participants