Hi This is for python projects Would it be a difficult task Pants #general

Hi! This is for python projects. Would it be a dif...

cold-vr-15232

02/26/2023, 10:12 PM

Hi! This is for python projects. Would it be a difficult task to change the implementation of vcs_version? I would need a different format for the output. Also, if the version is generated in a virtual file, how do I include it in a project's metadata? Regarding python packaging, I find it confusing and I am wandering rather aimlessly around....

enough-analyst-54434

02/27/2023, 2:01 AM

To change the format, you can use these: + https://www.pantsbuild.org/docs/reference-vcs_version#codetemplatecode + https://www.pantsbuild.org/docs/reference-vcs_version#codetag_regexcode To include include the version generated by the

vcs_version

target in metadata, this is how you'd do it if you use setuptools to package your project (this is the pyproject.toml setup, but you can do it with setup.cfg too if that's what you like): + https://www.pantsbuild.org/docs/reference-vcs_version#codegenerate_tocode + https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html#dynamic-metadata To debug, run `pants --keep-sandboxes=always package ...`and inspect the package sandbox to observe the relative path of the version file as well as its contents and play with the

version

configuration in

pyproject.toml

until you have things working how you'd like.

cold-vr-15232

02/27/2023, 8:37 AM

Thanks John! I didn't know that I could use dynamic metadata in pyproject.toml, that solves most of my questions. • codetag_regexcode is used for reading a version from a string, right? I'm not sure how it works together with the template. • The template docs say "Generate the version data using this format string, which takes a version format kwarg." but it's not clear if and how to use a different version format. What I want to use is "<latest git tag>.<commit # since then>-<git sha>"

cold-vr-15232

02/27/2023, 3:28 PM

Oh, but there is still an issue with python_distribution, as provides=python_artifact() can't use the version generated by vcs_version without a plugin... Or am I misunderstanding?

enough-analyst-54434

02/27/2023, 3:41 PM

I think you're misunderstanding. Have you captured a sandbox yet and poked around? That's pretty critical to finding your footing here I think.

cold-vr-15232

02/27/2023, 3:46 PM

Not yet, I will have to get home for that, but I have set up the project to use vcs_version and the dynamic version (printed by running the code) is ok, but the archive produced has the version number that is hardcoded in the python_artifact() declaration. I haven't checked the wheel metadata yet. The docs point to https://www.pantsbuild.org/docs/plugins-setup-py

enough-analyst-54434

02/27/2023, 3:50 PM

Why are you hardcoding a version in the

python_artifact

target? The whole point is to not do that.

cold-vr-15232

02/27/2023, 3:55 PM

Because if I leave it out I get an error

Engine traceback:

`in

package

goal` `InvalidSetupPyArgs: Missing a

version

kwarg in the

provides

field for libs/lib2:lib2. See https://www.pantsbuild.org/v2.15/docs/python-distributions.`

enough-analyst-54434

02/27/2023, 3:58 PM

That sounds like a bug.

cold-vr-15232

02/27/2023, 4:06 PM

I will open an issue then, but I think there is already one https://github.com/pantsbuild/pants/issues/16360

enough-analyst-54434

02/27/2023, 4:16 PM

So, I think you can route around the problem using the new support for

env("X")

in BUILD files +

.pants.bootstrap

which is a bash file sourced for env var exports.

enough-analyst-54434

02/27/2023, 4:19 PM

@cold-vr-15232 I think the issue you found is the right one. I think it may not be clear to maintainers exactly how this is broken though. I can add an example. Afaict it's broken by design. The

vcs_version

target is provided, but the rule code still forces you to specify a manual version - that clearly makes no sense / does not integrate.

enough-analyst-54434

02/27/2023, 4:21 PM

@cold-vr-15232 you'll need Pants 2.16.x, but the example use case for BUILD

env

is, in fact,

python_distribution

version: https://github.com/pantsbuild/pants/blob/main/docs/markdown/Using%20Pants/concepts/targets.md#environment-variables

enough-analyst-54434

02/27/2023, 5:01 PM

Ok @cold-vr-15232,

vcs_version

does work as advertised but you must explicitly set

generate_setup=False

in your

python_distribution

target. That seems like a minor bug, but I'm sure I don't understand the details. This works in the Pants repo:

Copy code

$ cat setup.cfg
[metadata]
name = test-project
version = file: _version.txt
author = Zaphod Beeblebrox
author_email = <mailto:prez@galaxy.gov|prez@galaxy.gov>
description = Smoke out vcs_version use in practice.
license = BSD-3-Clause
$ cat setup.py
from setuptools import setup


setup()
$ cat BUILD.setup
vcs_version(
    name="version",
    generate_to="_version.txt",
    tag_regex=r"^release_(?P<version>.+)(?:(?:rc|a|.dev)\d+)?$",
    template="{version}",
)

resources(
    name="project_metadata",
    sources=["setup.cfg", "setup.py"],
)

python_distribution(
    name="test-project",
    provides=python_artifact(
        name="test-project",
    ),
    generate_setup=False,
    dependencies=[
        ":version",
        ":project_metadata",
    ]
)
$ pants package //:test-project
08:57:51.59 [INFO] Completed: Run setuptools_scm for //:version
08:57:51.59 [INFO] Wrote dist/test-project-2.16.1.dev37+geb9eda8364.tar.gz
08:57:51.59 [INFO] Wrote dist/test_project-2.16.1.dev37+geb9eda8364-py3-none-any.whl
$ unzip -qc dist/test_project-2.16.1.dev37+geb9eda8364-py3-none-any.whl test_project-2.16.1.dev37+geb9eda8364.dist-info/METADATA | grep Version
Metadata-Version: 2.1
Version: 2.16.1.dev37+geb9eda8364

enough-analyst-54434

02/27/2023, 5:03 PM

The tag regex takes the closest tag and must parse from it a valid semver restricted to X.Y.Z form - it does not handle things like `rc0`; so you see me setting up a

tag_regex

that can handle Pants tagging convention and extract such a semver. It seems to require the X.Y.Z because it auto-bumps the version if not on the exact tag, but one or more commits after the closest tag.

enough-analyst-54434

02/27/2023, 5:10 PM

I'm not sure the patch version bump is the right thing to do there either - that seems like a small bug as well.

enough-analyst-54434

02/27/2023, 5:13 PM

Yeah. When you're exactly on a tag it definitely does the right thing:

Copy code

jsirois@Gill-Windows:~/dev/pantsbuild/jsirois-pants ((release_2.15.0)) $ ./pants package //:test-project
09:11:11.24 [INFO] Completed: Run setuptools_scm for //:version
09:11:13.40 [INFO] Completed: Building build_backend.pex from setuptools_default.lock
09:11:13.58 [INFO] Wrote dist/test-project-2.15.0.tar.gz
09:11:13.58 [INFO] Wrote dist/test_project-2.15.0-py3-none-any.whl

So it just seems like the patch bump + .dev... is overzealous since there is no such thing as the patch bump version to offset from, its the tagged version that is offset from. If you do end up using this

vcs_version

@cold-vr-15232 and you have an opinion on that bump behavior, definitely speak up.

cold-vr-15232

02/28/2023, 9:33 AM

Thank you very much @enough-analyst-54434! I'll go try the env() functionality. I think that for my requirements I will skip using vcs_version, and do it outside pants until we're certain what we want to have.

5 Views

Open in Slack

Previous Next