-
-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't WARN when a spec matches no relevant targets. #14904
Conversation
For discussion context: https://pantsbuild.slack.com/archives/C046T6T9U/p1647984328873369 |
|
I just think there should be one uniform principle here, and I'm generally on the side of not special-casing the empty set. This is particularly true re interaction with |
Addresses #14873 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kind of think the behavior should switch based on if the user is using --changed
or not. But in the absence of that change (which is more techincal and involved) this is good.
I'm skeptical I'll agree with this, but definitely will keep an open mind. See #14437 for the opposite direction. I still have a review queue from being out this past week and am trying to prioritize those for now - I'd appreciate waiting to merge this till I can review (hopefully by tomorrow at latest). |
How about not warn if you didn't provide any specs at all, and warn otherwise. That way: ./pants test # is silent
./pants test foo/:: # warns if there are no test targets in foo This should play nicely with Potential corner case is, if there are changed files, but none of them takes part for the requested goal.. |
What if there are changes but they don't affect any tests? |
Yeah, that's exactly what I was trying to hint at, in more general terms, with |
Also, I think the assumption that this condition is likely to reflect user error is open to debate. Except for possibly in the case where you literally do In any case, in the general category of "user used the wrong specs" errors, this only warns about a specific subset. What if the user used the wrong specs but they happened to have a test in them. Not the one the user intended but a test nonetheless: no warning. So this feels a bit ad-hoc. I guess the other important case this does catch is |
In these situations it helps me to ignore implementation and enumerate the possible user scenarios and the desired outcome. Then map the implementation to those cases. |
@Eric-Arellano @stuhood thoughts on this? |
I think that the semantics of the Silently doing nothing when a user has asked for something explicitly is not good. When they've asked for something via indirection like I do recognize that drawing a line between the |
my thoughts - i do think the warning/error is very helpful. reminder i added it after lots of confusion from users why pants wasn't doing anything. the autogenerated snippet of what to run is important too i agree changed since is confusimg, but that saying about babys and bath water hah |
Arguably this is true for glob specs as well. |
I agree somewhat. And that reminded me that we have done this all before! #8402. |
I care the most about the case where you don't give specs and we expect them. i also generally think |
Oh yeah! I agree that non-globs, non --changed, should warn. |
In these cases, the user intent is likely "if there are relevant targets, act on them", so warning is just annoying. However we still want to retain the warning if the user provided literal addresses, filesystem specs, or no specs at all. [ci skip-rust] [ci skip-build-wheels]
4c9a824
to
9ddf6bb
Compare
OK, fixed this to not warn only for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful! Yay!
This warning has its uses (e.g., if you accidentally ran on the wrong target),
but on balance, with hindsight, it seems more distracting and confusing than useful.
This is especially true with glob specs or
--changed
: "Run all the tests under foo/::"can be satisfied vacuously if there are no tests under foo/::, and ditto "Run all the tests
that are affected by git changes". So it's weird to issue a warning.
In such cases we should adhere to the principle that "the empty set is not a
special case", and just let things hold vacuously.
Of course we can still ERROR when a goal absolutely needs a target in order
to make any sense at all.
[ci skip-rust]
[ci skip-build-wheels]