https://pantsbuild.org/ logo
#general
Title
# general
f

full-oyster-41619

08/17/2020, 3:02 PM
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
h

hundreds-father-404

08/17/2020, 3:25 PM
Hello! I’m afk but yes what you are describing is possible :) I’ll comment how in a couple minutes
f

full-oyster-41619

08/17/2020, 3:59 PM
thx. I will wait for your comment
h

hundreds-father-404

08/17/2020, 4:14 PM
Let me know how that recommendation works out 🙂
Are y’all using purely Python or other languages too?
f

full-oyster-41619

08/17/2020, 5:05 PM
is the macro solution only working for version 2.0?
h

hundreds-father-404

08/17/2020, 5:05 PM
No, it should work for 1.30 as well
f

full-oyster-41619

08/17/2020, 6:15 PM
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.
h

hundreds-father-404

08/17/2020, 7:18 PM
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.
f

full-oyster-41619

08/18/2020, 6:26 AM
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)
h

hundreds-father-404

08/18/2020, 7:06 AM
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.
f

full-oyster-41619

08/18/2020, 10:41 AM
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
Copy code
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)
is there any way I can get the library path from inside BUILD file? something like
%(buildroot)
used in pants.toml
Copy code
python_library(
    name = "my-lib",
    sources = ['**/*.py'],
    provides=scm_setup_py(
        name="my_lib",
        description="my-lib",
        path="%(libpath)" # similat to %(buildroot) in pants.toml
    )
)
and the path would be taken when you run
./pants setup-py <lib-path>/<lib-name>
I could achieve this manually using
Copy code
python_library(
    name = "my-lib",
    sources = ['**/*.py'],
    provides=scm_setup_py(
        name="my_lib",
        description="my-lib",
        path="src/python/my_lib"
    )
)
but I want somehow to retrieve the path dinamically from pants code. My end goal is to create a versioning function like this
Copy code
def scm_setup_py(name: str, path: str , **kwargs) -> PythonArtifact:
    version = get_version_using_git_tag(path)
    return PythonArtifact(name=name, version=version, **kwargs)
3 Views