Sooo, turns out that integrating shell completions with pants as a built-in goal was easier than expected. Like, to the tune of minutes 🙂 However, this leaves me with a couple outstanding questions: 1. What should the completions "goal" be called?

./pants completions

- even if it's contrived, I like the idea of something like

./pants --completions

which kinda indicates that it's acting on the pants instance itself, rather than being a verb for some other work 2. What should the output of said pseudo-goal be? Print the completions to the console? Export to

dist

? This is probably a per-repo file, since it depends on what the installed backend packages are - so it may not be something trivially exported to a completions folder somewhere on the user's filesystem 3. Can this be auto-updated if the backend-packages change?

What should the output of said pseudo-goal be?

Maybe depends if we want to output for all shells, vs only one?

If you use the

completions

goal, then maybe people could configure (probably in

~/.pants.rc

) which shells they want: bash, zsh, … Then, plugins could register additional shell types for that goal (with a union). But, shell completion backends would need to be enabled via

~/.pants.rc

so that people can use esoteric shells without forcing projects to add support in their pants.toml And now, I’ve probably veered off into left field… Using the top-level completions would also make it discoverable when people list the available goals.

If I'm reading that right, and you'd want

./pants completions

called on each ... keystroke?

Not on every keystroke, just when the user hits

<tab>

to ask for completions

I mean, do-able, but at the mercy of the pants daemon

yeah - the pants daemon could do that, or we could have some kind of IPC to allow completions to talk directly to the daemon without firing off another subprocess.

For something that could be pre-generated, and only occasionally needs to change, this feels over-killy

a static export is probably better if completion generation is that slow.

./pants --version  0.64s user 0.10s system 26% cpu 2.817 total

That's for when there is a backend package mistake This is on the example-python repo:

./pants --version  0.56s user 0.08s system 78% cpu 0.816 total