Repository navigation
Move clap_complete_fig and clap_complete_nushell into clap_complete #5329
Description
Please complete the following tasks
- I have searched the discussions
- I have searched the open and rejected issues
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
Activity
epage commentedon Jan 24, 2024
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 commentedon Jan 24, 2024
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 commentedon Jan 24, 2024
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_nushellwas started outside of the clap project).Also, with #3166, there will be shells (like fig) that will be incompatible with what
clap_completewill 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 commentedon Jan 25, 2024
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 commentedon Jan 25, 2024
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 commentedon Jan 26, 2024
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.
epage commentedon Nov 24, 2025
Related: #5880
epage commentedon Nov 24, 2025
From #5880 (reply in thread)