Thoughts on getting rid of the concept of "basic v...
# general
Thoughts on getting rid of the concept of "basic vs. advanced" options?
The idea was that basic options are the ones you expect to set via cmd line flags, and end users might want to know about, whereas advanced options are typically set in config, and might be useful primarily for codebase admins
One upshot of this is that
./pants help <scope>
only shows the basic options for that scope, and you need to do
./pants help-advanced <scope>
to see all the options.
In practice, it seems like the "users need to know about this" vs "admins need to know about this" distinction happens more at the scope level
šŸ‘ 2
and in general there aren't that many options we expect end users to know about (given an end user dozens of options seems like a usability nightmare) and possibly those are best brought to light via documentation?
I'm not necessarily advocating for getting rid of the distinction, I can see arguments on both sides, but just curious if others have had thoughts or encountered issues with this
Have thought about that recently too, yea. I do vaguely think that the dividing line between CLI and config is still useful... but I don't think that "basic" and "advanced" read clearly enough as "usually CLI" and "usually config".
Also I think we can order the options so that command line ones show up first +1 for me. It's a gotcha that you have to use
. (Although mitigated by @fresh-cat-90827ā€™s PR
That is a great change that I was not aware of! Thanks @fresh-cat-90827!
ā¤ļø 1
āž• 1
šŸ‘ 1
he was looking at the help-wanted issues this morning and tackled it šŸ™Œ very much appreciated, polish like this goes a long way