Closed Bug 799680 Opened 7 years ago Closed 7 years ago
Support bash completion of mach commands
I mean, wouldn't that be cool, srsly?!
That would be cool, wouldn't it \o/ optcomplete looks cool. However, we use argparse. Not sure if it is compatible. Now that we register mach commands via Python decorators, we have a unified data structure of all the subcommands and their arguments. It should be relatively straightforward to convert that into a bash autocomplete file.
Not sure how we want to separate out the details of what goes where, but this generation should go in some sort of setup step (like writing a sane ~/.hgrc , etc)
This should be relatively straightforward, so making it a mentored bug. In mozilla-central you'll be working inside python/mach. The best way to do this is probably to create a mach command that looks at the data collected in registrar.py (it's a singleton for better or worse). Iterate over the data and spit out a bash completion file. Finally, hook it up as a mach command in main.py.
(In reply to Jeff Hammel [:jhammel] from comment #3) > Not sure how we want to separate out the details of what goes where, but > this generation should go in some sort of setup step (like writing a sane > ~/.hgrc , etc) I view this as 2 parts: 1) Figure out how to get bash autocompletion files from mach's internals 2) Hook it up via the mach frontend somehow For #2 I think in the long run we will have some kind of "setup my build environment" command. If we do things right, that can just call out to other mach commands. The long term vision is out of scope for this bug.
> The long term vision is out of scope for this bug. Sure, mostly noting for prosperity. We'll want to support (at least) two usecases: 1. update a particular user configuration item, in this case whatever files we touch to support bash autocompletion (e.g. .bashrc) 2. update all configuration items These should be idempotent (for a particular version of mach, anyway). This is all out of scope here but worth keeping in mind
With the work in bug 808336, mach command classes now receive information about available mach commands. This should make it much easier to write a mach command which outputs a shell completion script. I've also been contemplating the idea of mach having an "activated" mode similar to virtualenv. You run |eval `mach activate`| or similar and your current shell environment gains tighter mach integration (PATH contains where the main mach driver script is, the in-tree virtualenv is activated, etc). As part of this we could install the shell completion functionality into the current shell. Previous paragraph aside, I think a good first step is a mach command that outputs a shell completion script. We can figure out deep integration later.
(In reply to Gregory Szorc [:gps] from comment #2) > That would be cool, wouldn't it \o/ > > optcomplete looks cool. However, we use argparse. Not sure if it is > compatible. > > Now that we register mach commands via Python decorators, we have a unified > data structure of all the subcommands and their arguments. It should be > relatively straightforward to convert that into a bash autocomplete file. Due to this metadata, I think we could do this very well. But I would like people to be aware that https://github.com/kislyuk/argcomplete is trying to solve this problem from a general argparse perspective.
Nice find, Nick! That module does look promising! It even seems to offer an API with enough control to let us do some custom embedding work. I really need to find time to work on the "activate" feature...
I started this work before I saw the comments in this bug. The argcomplete project linked above looks like it might be a better solution, but this patch provides some basic functionality. After applying the patch, just source the bash-completion.sh script, or copy it to a location like /etc/bash_completion.d/mach if you have the bash_completion package installed. This only completes command names, and it is naive and slow (it runs mach every time it generate completions, which takes about 200ms on my Windows laptop).
\o/ Naive and slow is better than non-existent!
Mostly the same as the previous patch, but updated and polished slightly. Still slow on Windows, but not unusably slow.
By the way, I experimented with caching the command list in a file to improve performance, but I got hung up trying to write code to expire the cache. It doesn't help that there's no "stat" command in the mozilla-build shell. :(
Comment on attachment 750161 [details] [diff] [review] patch Review of attachment 750161 [details] [diff] [review]: ----------------------------------------------------------------- Nice work! This reminds me that I'd like to eventually add hidden commands. As it stands, this new command just clutters help output, IMO.
Attachment #750161 - Flags: review?(gps) → review+
Severity: normal → enhancement
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.