I've implemented deep bash completion integration within the library. Work towards #75. A bash completion script can call into any tool using Kingpin by using a new flag
Opening this PR to get some eyes on it, and see how it can be improved. Happy to add docs once we're happy with the overall structure of it (Since this does bring some new API):
Users will be presented with completion options for:
There's a bit of re-shuffling in this PR, including a new mixin (
Additionally, a lot of logic from
An additional argument has been added to
Included are two scripts
Hi @nickw444, thanks for the PR. I've had a look, but I'm still pondering some design/usability concerns.
I really like the hint approach, this could also be useful for eg. generating more useful help.
Anyway, I'll have a bit more of a think about it, but at the moment I'm thinking that if 1. above is addressed, I'll probably just merge it because it's a great start, then if the underlying implementation changes it will be easy to do.
Hey @alecthomas thanks for the comments. I understand your concerns in all of your above points.
I've moved the "support" scripts into the
Consider this: when distributing a package, (specifically a .deb), the package maintainer will usually add a
Alternatively, package maintainers need to inform users that they can add additional lines to their
However, personally, I feel this isn't a great end user experience. Anyway, with that all being said, it's definitely the right way to go to move the scripts into kingpin, where a package maintainer can generate these scripts after compilation and add them to the distribution.
I originally felt that keeping completions outside of the app was the best idea, as it's more isolated and controlled (plus an easier feature IMO :P ), but, it didn't give users of kingpin great options for handling dynamic arguments without re-generating the script every time.
A good example of such a use case is where you have a CLI tool which reads from an hosts file and provides completion of possible known hosts. By reaching into the application and performing a
I originally attempted this, and also implemented a hybrid, however due to how bash (and ZSH) handle completion selection, a space will always be added (unless there are multiple options to choose from).
The original implementation I speak of would output every possible
I've added documentation and tests. Let me know if you've got any additional comments :)
That's a good point. Looking at the example completion code, it looks like it could be super powerful. Very nice.
That's a bummer, but good to know you had the same thought :)
I think once you've addressed the few minor comments I made, this LGTM.
I've made the requested modifications. I removed that
However, I still can't get a green build. I've attempted using a relative package import, and not importing at all. What do you suggest I do to remediate this?
I think I may have accidentally by chance found the issue you were having:
The shell will respond with completion that doesn't seem consistent with kingpin completion. This is because we didn't source the kingpin completion script.
I can reproduce this issue now. I'm sure this is because of the pattern being used to create this command line tool. Notice how the commands are instantiated from the kingpin library, rather than from an
All the flags work because they're defined on the command.
Look at the completion example and how the commands are defined: