https://pantsbuild.org/ logo
Join Slack
Powered by
Thanks ahead of time!
# general
c
Thanks ahead of time!
e
That raise is at least three years old, so you're likely the first to use setup-py in this way. The raise was probably added as part of an opposite-confusion issue where some pants users were confused by noops; ie: a fix for your issue will noop on this command line instead of - arguably - helpfully erroring to prompt the user to re-evaluate what they're doing: 
./pants setup-py src/java::
I don't see an issue with a PR to fix this, but globally I think this is also whack-a-mole. Perhaps this indicates Pants should know about a "batch" mode vs an "interactive" one. With this concept in-hand, 
--changed
would imply batch and in batch tasks would not error if their was no work. In interactive mode they perhaps uniformly would error with no work when explicitly listed as goals on the command line. This is all a bit tricky to get right in both cases.
a
"`--changed` would imply batch" is really interesting
it seems like a perpendicular enough axis to things like 
--quiet
too
would definitely assume it's tricky to get right. that's a distinction i hadn't thought fully about but started to with e.g. making glob expansion failures only warn if none of the default ones matched
the "batch"/"interactive" split seems robust
i really like this idea, it seems pretty strange to have to check whether there are any changes in order to run your command that runs on changes safely
it could also be an opportunity to formalize some of this exit with failure/don't exit with failure logic that all tasks implicitly have, it seems like if conforming to this option could encourage centralizing that logic it would make it easier to understand for other tasks depending on the products
it could take the form of e.g. an argument to 
self.invalidated()
, or maybe some other override
wait this is great because tasks nooping performantly/without error is already a problem
that comment in 
select_interpreter.py
about having to make an interpreter anyway for simplicity downstream always rankled me -- not as a bad idea, but that it was necessary
now i'm just having wild thoughts about v2/v1 engine task integration sorry
c
Hey, thanks for your responses here--I’m a few hours ahead, so I was long done for the day when you responded 🙂 If I can pick yours brains a bit further, I’m open to ideas to workaround it. Also, if I were to submit a PR, would the pants team be willing to backport to 1.8 on a 1.8.1 release?
a
it would likely depend on how much it ends up changing pants internals -- for fixing your problem, i think a PR that is backportable seems way reasonable but john will know that way more than me
c
Cool, I think the batch/interactive fix would certainly workaround the issues without introducing a breaking change.
I will wait for a green light before pursuing a fix.
a
i think that's really feasible too actually i just think the batch/interactive thing is so cool
i just assumed it couldn't be backportable it totally could
i'm mostly new here
c
👍🏻
e
@creamy-activity-5659 I think filing an issue and whacking the mole is the way to go here to get this cherry-picked to 1.8.x. Even if the batch / interactive idea survives scrutiny, that's a larger change I'd want wider discussion / acceptance of.
c
Great, thanks John. I’ll move the conversation to github and file an issue. Thanks again for your time!
Open in Slack
PreviousNext
Powered by