https://pantsbuild.org/ logo
Join Slack
Powered by
I type it out at the end of the command line: `./v...
# development
h
I type it out at the end of the command line: 
./v2 test --debug src/python/pants/option/config_test.py --pytest-args="-k Config -vv"
a
what is 
./v2
?
and also, i still want to have passthrough args if possible instead of having to remember individual option names
h
script I have to run 
./pants --no-v1 --v2
👍 1
w
Eric wrote a design doc there: if you see another way around it, I don't think anyone is opposed to passthrough args in v2.
a
and the design doc says the plan was to support both 
--run-args
as well as 
--
which confused me
sounds good
w
Mm. Yea, that doc didn't reach the conclusion I remembered.
h
Ah, I see. Originally I was trying to find some way to preserve the 
--
style but DWH and Benjy’s comments made me realize the benefits of consolidating around the option always living on a subsystem. https://docs.google.com/document/d/18-WFAYiktq3DAfOQPrnU5yaycT6V1K27yrnFPoGgTIA/edit?disco=AAAAD-H3BBQ
a
i think that’s a good argument for them always living on a subsystem, which i agree with, but i don’t think that precludes the trailing -- style when it’s unambiguous
👍 1
h
Awesome, glad we’re on the same page with living on a 
Subsystem
or 
GoalSubsystem
i don’t think that precludes the trailing -- style when it’s unambiguous
I do think it’s possible (albeit likely difficult to implement), but I argue that I don’t think it’s worth it. I responded in https://github.com/pantsbuild/pants/pull/9075#issuecomment-582982219 just now about 
--run-args
and included in the last piece the possibility of maintaining traditional args for other goals
a
i don't think anyone else thinks it's worth it either
w
see my response on the ticket.
a
ah -- thank you!
w
so, based on this, we should probably remove this deprecation rather than removing the facility:
Copy code
02:07:22 [WARN] /Users/stuhood/src/pants/src/python/pants/backend/python/tasks/pytest_run.py:587: DeprecationWarning: DEPRECATED: Using the old style of passthrough args for Pytest will be removed in version 1.26.0.dev1.
  You passed arguments to Pytest through either the `--test-pytest-passthrough-args` option or the style `./pants test.pytest -- -k FooTest --quiet`. Instead, pass any arguments to Pytest like this: `./pants test :: --pytest-args='-k FooTest --quiet'`.

This change is meant to reduce confusion in how option scopes work with passthrough args and to prepare for Pytest eventually exclusively using the V2 implementation, which only supports `--pytest-args`.
  return self._run_pytest(fail_fast, tuple(test_targets), workdirs)
h
I continue to dislike the traditional style due to the frequency of ambiguity, but I’ll approve a PR if you do want to remove the deprecation So long as V2 has a mechanism for passthrough args, which it still would have
a
so my vision of passthrough args would specifically involve erroring out immediately on any ambiguity
w
i don't know if we know how to do that for subsystems, but if you have a suggestion, please comment on the ticket linked above.
but. in practice, the unavoidable ambiguity is the same ambiguity that exists in v1, which hasn't caused an issue
(there are N test tasks in 
test.*
, and you can only use passthrough args when you're running an umambiguous set of targets, and ... that's ok)
h
That’d make me feel much better with traditional passthrough args. At that point, I don’t see much value in keeping it because we would presumably keep the more explicit form of 
—isort-args
so that you can pass when there is ambiguity. But I won’t die on this hill - so long as we do keep the explicit form always
👍 1
but. in practice, the unavoidable ambiguity is the same ambiguity that exists in v1, which hasn't caused an issue
I don’t agree. I was very confused by task scopes when learning Pants at Foursquare; passthrough args were part of that. Even if it’s fine for pants users with experience, I find the traditional form difficult to teach new users because you must warn about all the special cases. Generally, we have two ways of doing things: an explicit form that always works and this traditional form that sometimes works / has a lot of special cases I found when teaching that special cases tripped up my students more than I’d expect. While it doesn’t perfectly map (new Pants users are not 7th graders learning to program for the first time), I since then have become suspicious of UX that involves special cases, particularly when we have an alternative that always works
w
Scopes are unrelated to passthrough args
./pants test $pyfile -- -k $method
works, because the passthrough args are applied to all tasks in all goals*
Only one of the tasks actually runs, and so junit (and etc) doesn't explode
a
super naively, we can just add a mutable flag that records whether passthrough args have been accessed already in the pants run, and explode if so
Open in Slack
PreviousNext
Powered by