https://pantsbuild.org/ logo
Join Slack
Powered by
I got ignore CLI args working, so you can do `./pa...
# general
h
I got ignore CLI args working, so you can do 
./pants test project:: '!project/integration_test::'
šŸŽ‰ The issue is that you have to quote the 
!
or your shell won't be happy. So @curved-television-6568 suggested instead using 
-
, like 
-project/integration_test::
, which mirrors how 
--tag
works. However, that causes ambiguity with short-flags like 
-dmy_custom_dir
, which equals 
--logdir=my_custom_dir
. How do people feel about getting rid of *the ability for arbitrary short flags, to make room for ignore CLI args?
āœ… 1
We only have a few short flags atm: ā€¢ 
-l
, aka 
--level
ā€¢ 
-d
, aka 
--logdir
. Which doesn't look like it actually is wired up to anything... ā€¢ 
-h
, aka 
--help
ā€¢ 
-v
, aka 
--version
*I think some of those are good, especially 
-h
and 
-v
, and maybe 
-l
But generally, I believe that short flags are an antipattern w/ Pants, given how many options we have and how many things Pants does Short flags are great with tools that have ~one purpose, like Pex and pip. But with Pants, it's too vague imo
If we really are attached to the brevity of 
-ldebug
vs 
--level=debug
(6 char difference)...we could special case it in our arg parsing code Altho I encourage consistency. Fewer things for users to learn My proposal is to special case 
-h
, 
-v
, and probably 
-l
given how frequently it's used But otherwise, get rid of 
-d
== 
--logdir
and ban short args for plugin authors
c
Another observation here is that from what I can tell, those short flag options are all bootstrap options, right? So must go before any goals. So we could simply drop shortflag support for subsystems to accommodate negated target specs.
āž• 1
h
My proposal is to special case -h, -v, and probably -l given how frequently it's used
This was easy to get working with 
args_parser.py
šŸ™‚ So if people agree w/ the proposal, I'm confident we can implement
c
Is it possible to not specialcase those particular flags, but rather pre goal flags vs post goal flags?
h
Possibly. In my implementation so far, I only had to special case 
-l
. 
-h
and 
-v
are already handled by being 
BuiltinGoal
This is all it is:
Copy code
if not arg.startswith("--") or arg in {"-linfo", "-lwarn", "-ldebug", "-ltrace", "-lerror"}:
            return False
-d
is an issue tho because it's not an enum and can have an arbitrary value. We'd have to do something like 
if arg.startswith('-d')
. But that means we might not recognize the value 
-dir
as a spec..., thinking you mean 
--logdir=ir
hah
šŸ‘€ 1
fyi, this is all it took to make 
arg_parser.py
happy, assuming we are fine removing 
-d
and banning plugin authors from using short flags https://github.com/Eric-Arellano/pants/commit/7f66bf4643fb1916b079380c4eed3b6ebda235b8 I would also add validation to 
parser.py
that short flags aren't being used beyond the blessed ones of 
-l
, 
-h
, and 
-v
h
Yeah I'm fine with this. The 3 you mention are probably important, but we can kill 
-d
šŸš€ 1
ā¤ļø 1
b
Party hard!!!
Just to clarify, how does argparse handle 
-
now? In bazel you have to "escape" it, 
bazel test //... -- -//foo/...
But that'd mess with passthrough args. Can we get this working without 
--
?
c
Yep, without 
--
b
Party hard
3 Views
Open in Slack
PreviousNext
Powered by