Hey, Any chance someone can review <this PR>? On...
# general
m
Hey, Any chance someone can review this PR? On a different matter, I’m seeing an unexpected behavior when running
pants --no-pantsd --no-watch-filesystem --changed-dependents=transitive --changed-since=<commit-sha> publish
I have two packages, X and Y, where X consumes Y (
python_sources()
of Y is declared as a dependency in the
python_sources()
of X). I also have a custom plugin that intercepts usages of
python_artifact
(as part of
python_distribution
) When I run the command, although only X changed, I see my plugin runs on both X and Y. Is that intentional? (I think the
package
step runs on both, while
publish
only runs on X) Thanks!!
h
Well, I can imagine that Y's
python_artifact()
would get evaluated as part of BUILD file parsing, even if it doesn't end up being published. Do you see anything beyond that happening?
m
My plugin code is being run, which surprises me Can it be because the version is being calculated as part of
python_distribution
?
If so, is is possible to somehow tell if the currently evaluated
python_distribution
target is included in the passed
--changed-since
value?
ok I think I understand. Because X needs the version of Y (for its setup.py), it invokes my plugin to get the version but my plugin assumes it invoked for Y only when Y changes. What do you suggest to do? basically my plugin is used to create git tags and calculate semvers
h
Ah, right
good detective work
m
any recommendations? can I somehow tell if a module I am calculating the version for will be published?
@happy-kitchen-89482 wdys?
h
Hmm, I can't think of a way to detect this inside your custom python_artifact()
That code has no context to the outside world, I think
It only sees the kwargs passed to it
What are you doing in that custom SetupKwargsRequest
m
I’m calculating the next version, and creating a git tag with that version I’ll provide an example: X uses Y only X is changed, but when setup.py is generated for X, it needs to know the version of Y. Since my script handles fetching the next version, it returns a version for Y that will not be published (it will have a tag tho)
h
I see
Hmm, I'll need to chew on that one
Probably we need a different hook into the version generation, which is a thing quite a few people have asked for. There's a ticket somewhere...
We need a little bit of design work on this, because just doing it in a BUILD file macro clearly isn't sufficient
Let's move the discussion to that ticket? Maybe start by explaining your use case over there, and we can use that to guide some design work.
But it's clear that we need to do... something, here
m