https://pantsbuild.org/ logo
#development
Title
# development
w

wide-midnight-78598

09/26/2022, 7:39 PM
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?
🚀 2
🤘 1
h

hundreds-father-404

09/26/2022, 7:48 PM
What should the output of said pseudo-goal be?
Maybe depends if we want to output for all shells, vs only one?
Can this be auto-updated if the backend-packages change?
Not currently. Relates a little to https://github.com/pantsbuild/pants/issues/12014 I think
p

proud-dentist-22844

09/26/2022, 8:23 PM
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 you made a
./pants completions
goal, I can imagine a zsh completion plugin that calls that to add contextual completions on the fly. For the zsh completion, I can imagine an oh-my-zsh plugin that would call
./pants completions test --
given the user typing
./pants test --<tab>
to get the valid args in that context.
w

wide-midnight-78598

09/26/2022, 8:30 PM
If I'm reading that right, and you'd want
./pants completions
called on each ... keystroke?
p

proud-dentist-22844

09/26/2022, 8:31 PM
Not on every keystroke, just when the user hits
<tab>
to ask for completions
I’ve seen a variety of zsh plugins that do that kind of thing to get completions on the fly in a subprocess.
w

wide-midnight-78598

09/26/2022, 8:32 PM
I mean, do-able, but at the mercy of the pants daemon
on my computer at the moment, that would mean re-building the native code for some reason, but in reality, like 0.5-1s of delay on each tab
p

proud-dentist-22844

09/26/2022, 8:33 PM
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.
dang. That’s a lot of delay.
w

wide-midnight-78598

09/26/2022, 8:34 PM
For something that could be pre-generated, and only occasionally needs to change, this feels over-killy
p

proud-dentist-22844

09/26/2022, 8:34 PM
a static export is probably better if completion generation is that slow.
w

wide-midnight-78598

09/26/2022, 8:37 PM
./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
If every tab took that long, I'd instantly stop using them - that's not even completions
Actually generating the completions:
./pants completions  0.71s user 0.12s system 60% cpu 1.365 total