search

clap-rs / clap

A full featured, fast Command Line Argument Parser for Rust
docs.rs/clap
Apache License 2.0
13.66k stars 1.02k forks source link

Move clap_complete_fig and clap_complete_nushell into clap_complete #5329

Closed jcgruenhage closed 5 months ago

jcgruenhage commented 5 months ago

Please complete the following tasks

Clap Version

4.4.9

Describe your use case

As a distro maintainer, I want to ship shell completions for all shells shipped by my distro. Even if a package ships completions generated with clap_complete, the ones for nushell for example aren't included, because people only take the ones listed in clap_complete directly. See https://github.com/mitsuhiko/minijinja/pull/403/files#diff-cea125128a0bc3a52233a2d72ca6519778801f05f6e5c45612dcf6045c1c0075R33-R37, to see why.

Describe the solution you'd like

I'd like to move clap_complete_nushell and clap_complete_fig into clap_complete itself. This way, it's easier to generate completions for everything.

Alternatives, if applicable

It would also be possible to keep them in separate crates, which are then depended upon by clap_complete, with that inclusion being hidden behind feature flags.

Additional Context

No response

epage commented 5 months ago

This is intentional as we aren't as committed to the same level of support for these shells. If we had this model back when Elvish was added, it would be in a separate package as well.

Similarly, when #3166 is stabilized, we might be changing what shells are supported in clap_complete.

jcgruenhage commented 5 months ago

Wouldn't it make more sense to hide the shells with less commitment behind a feature flag like "experimental_shells" then? That'd still make it a lot easier to package completions for those tools as a package maintainer for distros.

epage commented 5 months ago

Its easier to manage the support level as a distinct package, rather than dealing with moving a package in and out (e.g. clap_complete_nushell was started outside of the clap project).

Also, with #3166, there will be shells (like fig) that will be incompatible with what clap_complete will turn into. When we make the transition to shell-native completions to rust-native completions, I expect we'll migrate all of the shell-native completions into individual packages which will be at a lower level of support.

jcgruenhage commented 5 months ago

So that means there won't be a way to iterate over all shells anymore in the future? Then package maintainers would have to do a lot more patching to ensure all shell completions are built.

I understand why that makes sense from a clap PoV, but as a distro maintainer this does make my life a bit harder.

On a more positive note: Very much looking forward to rust-native completions :)

epage commented 5 months ago

Isn't this a choice for the CLI maintainer? It seems odd for a distro to be trying to extend a program beyond what the maintainer supports.

jcgruenhage commented 5 months ago

Yeah, but the patches for those CLI tools often come from distros to the upstream repo. The cases I've seen are more that the upstream maintainers aren't even aware that they could improve their UX by providing (more) completions or a man page. There's probably a dozen or so cases where I've packaged CLI tooling and upstreamed generation of completions and man pages so that we could ship them in Void Linux.

Ideally, the patch does land upstream, but providing a man page and cli completions auto-generated from a clap definition where the patch does not land upstream does occasionally happen too. Considering we're not changing how the tool itself works, I think that's fine too.