:bike: :derelict_house_building: on shell complet...
# development
w
šŸš² šŸšļø on shell completions naming (i.e. the goal that generates the shell completions script):
./pants complete
./pants completion
./pants completions
Other? I wanted something like
./pants --completion
- but since it's a built-in goal, I can't use options-style naming
If it's becoming something closer to a top-level goal, I would have preferred a verb - but then that's closer to
generate-completions
c
There is a way to have it as an option style, but with caveats that itā€™ll also be a top level thing as you have above.. https://github.com/pantsbuild/pants/blob/1870d37d7ca8096ff3bd15c6e25fbb3c358a0af3/src/python/pants/goal/help.py#L93
hmmā€¦ maybe if
name = "_completions"
and
aliases = ("--completions",)
would hide the not option versionā€¦
w
Oh, yeah, I saw the aliases - but since it ends up in both, it kinda becomes a "goal"
c
yeah, itā€™ll still be a goal..
btw, Iā€™m +1 for
completions
ā€¦
šŸ‘ 1
w
So, it would end up on this page fundamentally (https://www.pantsbuild.org/docs/reference-all-goals), even with the underscore
h
This is for the goal that generates a completions shell script?
w
Yep
b
(Is this in a plugin? Thats off by default and the user opts into?)
c
builtin goals canā€™t be in plugins
b
It could be a goal provided by a plugin tho, doens't have to be "builtin"
c
true, just went of the OPā€™s
but since itā€™s a built-in goal,
b
I ask because I think eventually it'd be dope if this didn't exist in favor of Stu's idea to autogen relevant exported artifacts (like venvs, or this file) and pulling the plug on a plugin goal is easier to stomach than a builtin one šŸ˜‰
c
well, thatā€™s the exact suggestion I had with the builtin goal alias šŸ˜‰ : https://github.com/pantsbuild/pants/blob/1870d37d7ca8096ff3bd15c6e25fbb3c358a0af3/src/python/pants/goal/help.py#L112-L115
b
IDC about the name, but I don't want us to hog the goallist unless enabled. Especially considering we can see a future where the goal isn't required
w
@curved-television-6568 Was providing context to Josh's comment about why it's a builtin
c
Oh, k šŸ˜›
w
I mean, my original idea was for completions to be part of
export
c
IDC about the name, but I donā€™t want us to hog the goallist unless enabled. Especially considering we can see a future where the goal isnā€™t required
Well, if weā€™re to adopt the policy of ā€œhidingā€ rather than removing features for stability reasons (Joshā€™s deprecation policy work) then we would likely keep it around regardless, but if not needed then as a hidden goal.
b
We could also just pile in on the auto-gen feature >:)
šŸ‘ 1
w
šŸ¤·
c
Keeping a builtin goal around I donā€™t see as such a big burden and is easy to implement today, where as the alternatives I believe requires more work (also on the design side) and the backend rules for the completions would likely be very close then as to now so my vote be to do whatā€™s easy to unblock this now, and for the future we could simply hide it if it becomes an obsolete goal. No strong preference either way besides that šŸ˜‰
b
Yeah don't let me stop you. Just trying to peer ahead.
šŸ’Æ 1
c
As am I šŸ˜„ (that is, I appreciate the balancing of a pro vs con approach to find the best way forward). no light without dark etc šŸ˜›
h
Does folding this into
export
make sense?
./pants export --bash-completions
?
šŸ’” 1
Now that we have plugin options for subsystems (šŸŽ‰), we can make
export
a sensible place for this kind of thing
b
(FWIW because of the builtin-nature it might need tobe baked directly into
export
. Thats OK though)
w
Has export been modified in the last month or so? I thought it only worked for venvs? Original idea from July (https://github.com/pantsbuild/pants/pull/16200#issuecomment-1192063349) was as part of export or export-codegen
And I'm all +1's for fewer goals
h
Currently the only thing export exports is venvs, but it was always intended to be a general ā€œget stuff out of Pantsā€ goal. The problem was how to specify what you want to get out of it in a pluggable way. Plus, it tries to use cmd-line specs in a way that isnā€™t generically useful. But now that we have pluggability of options, the path is open for
export
to be what it was meant to be
šŸ‘ 1
w
So long as I can access
help-all
, I have zero qualms moving to
export