https://pantsbuild.org/ logo
Join Slack
Powered by
in the `python_distribution.provides.version`... i...
# general
b
in the 
python_distribution.provides.version
... is it true that the ONLY thing which cares about this is when you do 
setup-py
an actually build an artifact?
h
Yes, this is true. Atm, the only built-in functionality that cares about it is 
setup-py
You can also write your own plugins, though, which also use that value. (Btw, we try to use threads with Slack to keep conversations more organized)
How come?
h
Yes, that is the version that your wheel will have, nothing else uses it.
There are various ways to customize how that version is generated though, in case hard-coding it in BUILD files isn't what you want.
h
b
basically, we have an integration flow where version is by git (source of truth)
and we don't want individual devs setting "version" on anything except through the programatic integration process
but if the 'build a pkg' process wants to find the version in a metadata file such as BUILD or pyproject.toml, that value has to get written into place there somehow
so I have been looking at various points in our flows where that could happen
best place looks like the very end - litterally right before we would call e.g. 
pants setup-py -- bdist_wheel....
the subpkg in the monorepo and the semver are in the build envioronment at that point, so I'd 
sed
the semver into place in BUILD
just before calling 
pants setup-py
but that means we're not carrying the "definitive" versions in BUILD files in git trunk
so I was wondering if anything else in pants cares
make sense?
h
Is anything else going to read the BUILD file for determining the version, or this is solely to placate Pants when running 
./pants setup-py
? If it’s only for Pants, you can write a plugin that will run those commands to determine the version for you and dynamically give it to Pants. In other words, the 
version
will never be explicitly added to the 
BUILD
file.
b
I'm fairly sure that nothing we have needs to see the version in a BUILD file other than pants itself
and it is much easier to 
sed
that file than write a plugin 🙂
e.g. 
version="FIX_ME_AT_BUILD_TIME"
is what would forever be in version control 🙂
(or similar)
h
Cool, sounds good! Agreed. Main motivation for a plugin would be if a) the logic is more complex than you could do with the script, such as needing to consider the target’s dependencies, and b) so that 
./pants setup-py
Just Works without needing a wrapper script. But otherwise, doing this via sed and a wrapper script is totally acceptable and keeps it simple Let us know if you do end up being interested in writing a plugin, for this or something else. We’re happy to help
b
thanks
our main use case for the dependency smarts is being able to call 
pants --since.... --...=transitive test
without knowing which sub pkgs to do and getting it right
💯 1
(without a human explicitly providing that input)
5 Views
Open in Slack
PreviousNext
Powered by