Hi. We currently have a plugin that captures our python_distributions and adds a build number using the SetupKwargsRequest union rules. We have a library that is dependent on another one of the libraries. So library A depends on library B. If we make a change to library A, but not to library B, library A builds a requirement pinning to the build number version. Because no changes were made in library B, that never gets published. How can we get library A requirement t version of library B to use a * instead of the build number, or use the last previous successful build.

Not sure I understand the issue. Are you saying that library A's change causes a bump in the build number for library B?

Yes, because the SetupKwargsRequest runs for each library, the build number gets populated on both libraries regardless of it was changed or not.

I see, so A' depends on B' but B' doesn't actually exist?

It is an incrementing number. We wanted to keep semvar sematics so we avoided SHA or git hash.

So it sounds like changing the requirement to

*

wouldn't be correct?

If we can determine there was no changes, I would substitute with a *. but generically we can't because sometimes we change both at the same time and both will need to get published.

If you can determine that there were no changes when? The changes to a dep can happen after you publish

Library A (houses compiled protobuf definitions) Library B (manipulation of objects based on a single protobuf from library A) Scenario 1: Library A has changed, library B has not changed: Library A semvar version has updated to a new version. Library A will get published with a new semvar and new build number (like the git commit position) Library B will get published with the same semvar, but new build number since its dependency changed. Library B get published with a requirement of Library A which is also published. Scenario 2: library A has not changed, Library B has changed, : Library B semvar version has been updated to a new version. Library B will get published with new semvar and build number, but the requirement to A matches the current build number and library A does not get published. Scenario 3: Library A has changed, library B has changed: Library A semvar version has updated to a new version. Library B semvar version has updated to a new version. Library A get published, Library B get published with a requirement to library A. build numbers match.

Thanks - can you add specific semver+build number examples to all these (just edit the post?)

Library A (houses compiled protobuf definitions) Library B (manipulation of objects based on a single protobuf from library A) Scenario 1: Library A has changed, library B has not changed: Library A semvar version has updated to a new version. (1.1.0 from 1.0.0) Library A will get published with a new semvar and new build number (like the git commit position) (1.1.0.120) Library B will get published with the same semvar (1.0.5 -> previously published at 1.0.5.110), but new build number since its dependency changed (now at 1.0.5.120). Library B get published with a requirement of Library A which is also published. Library A (1.1.0.120) depends on Library B (1.0.5.120). Library B was never built with this version. Scenario 2: library A has not changed, Library B has changed: Library B semvar version has been updated to a new version (1.1.0 -> from 1.0.5). Library B will get published with new semvar and build number, but the requirement to A matches the current build number and library A does not get published. Library B gets built with (1.1.0.120). Library A also gets built with 1.0.0.120) since no changes, no semvar change. Scenario 3: Library A has changed, library B has changed: Library A semvar version has updated to a new version (1.1.0). Library B semvar version has updated to a new version (1.1.0). Library A get published, Library B get published with a requirement to library A. build numbers match. Both get built with version 1.1.0.120.

Great, thanks for the extra detail. To clarify something, in Scenario 1 you say that B gets "published" but not "built", and in Scenario 2 you say that A gets "built" but not "published"?

I think the approach we are taking here isn't viable with the pants system. We are planning on rethinking how we want to do our versions for python artifacts, especially around the scenarios where libraries depend on other libraries.

Yeah, I think Pants can do this with a plugin, but first there would need to be very rigorous definitions of when things get published and how the dependencies on them are adjusted. In this example it seems like everything has to move in lockstep, because versions of everything get bumped (via the build number) even if not all of them changed.

Yah correct. We would need more logic here to determine if things changed. I want to look at trying to use the digest hash of the artifact because then that would not change if the code has not changed (is that right?)