hello all. I just started with pants and want to use it for version management in python libraries. Is there any functionality in pants that handles version bumps of libraries during build? For more details on this please see the ticket I've opened a couple of hours ago https://github.com/pantsbuild/pants/issues/10633

Hello! I’m afk but yes what you are describing is possible :) I’ll comment how in a couple minutes

thx. I will wait for your comment

Let me know how that recommendation works out 🙂

is the macro solution only working for version 2.0?

No, it should work for 1.30 as well

thx. will try this and see what power it has. your example looks more like setting a default version. I am looking for something like semver version bump similar to how pants publish works for java (https://v1.pantsbuild.org/publish.html): "_The publishing mechanism uses Semantic Versioning ("semver") for versioning. Versions are dotted number triples (e.g., 2.5.6); when Pants bumps a version, it specifically bumps the patch number part. Thus, if the current version is 2.5.6, Pants bumps to 2.5.7. To publish a minor or major version instead of a patch, you override the version number on the command line._" In a nutshell I do not want for dev to worry about managing versions for libraries, but only manually intervene when is a minor/major change in version.

Ah, I see. Yeah, what I described with macros would still require a manual bump of the version in that

macros.py

file, and it sounds like you want something more automated. To clarify, do you want the version to automatically bump every time that you run

setup-py

? Note that

setup-py

only builds the distribution, it won’t actually publish it like those JVM docs on the

publish

goal do.

I want something more automatic. I do not need the publish feature since I will use twine for that. But I do not want to manage the version bumps manually. When you get to internal dependencies that will complicate a lot (you need to bump parent libraries when child changes). I have been using the python's internal scm versioning for a library (

use_scm_version: True

) , but this is not a good fit for mono repo (I will have a one version fit's all scenario, which has multiple disadvantages, like building unneeded libraries and loosing semanting versioning per project)

Okay, thanks for explaining your use case. Similar to the publish goal’s implementation, you’ll likely want a file that gets checked in to keep track of the version(s). Of course, that could get changed automatically, but it’s still checked in to the repo. Is that inline with what you’re thinking? I’m wondering which sounds like a better fit for what you’re envisioning? • every time the user runs setup-py, automatically overwrite that versions file. It’s up to the user to decide if they should check that in. • Add a new goal like

custom-setup-py

that behaves really similarly to the built in

setup-py

, but will update the version . Maybe you add some options to decide what to do, eg to override the version to a certain value.

I am thinking of the following use cases (taking into consideration flexibility): 1. keep the functionality of building a python library with

./pants setup-py <lib> -- sdist

, but add a way to define a function that calculates the version. this function can something like

f(lib_name) -> lib_version

. This will give the users the flexibility to bring their own version algorithm. The macros example that you showed presents a similar scenario, but from what I've read pants cannot use imports inside the macro and because of this you are very limited in the versioning algorithm functionality. maybe there is another way of doing this, like using a plugin (didn't deep dive into that yet). 2. Add

--transitive

to

setup-py

goal (

./pants setup-py --transitive <lib> -- sdist

. This will use the same versioning mechanism described above, but will build also the transitive libraries of the specified library. Libraries could have different versioning functions implemented. This will be useful when you have to make a change in a child library and want to build all parent libraries. Pushing will become very easy, because you could use twine to upload all the dist dir content. For example, one implementation of the function that generates the version for a library, can be the one that was described in the java publish scenario

uses Semantic Versioning ("semver") for versioning. Versions are dotted number triples (e.g., 2.5.6); when Pants bumps a version, it specifically bumps the patch number part. Thus, if the current version is 2.5.6, Pants bumps to 2.5.7. To publish a minor or major version instead of a patch, you override the version number on the command line.

The pushdb: To "remember" version numbers, Pants uses the pushdb. The pushdb is a text file under source control. It lists artifacts with their current version numbers and SHAs. When you publish artifacts, pants edits this file and pushes it to the origin.

another implementation might be a function that returns the version used in scm (similar to

use_scm_version: True

functionality in setup-py)