Hi! This is for python projects. Would it be a dif...
# general
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....
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
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
configuration in
until you have things working how you'd like.
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>"
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?
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.
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
Why are you hardcoding a version in the
target? The whole point is to not do that.
Because if I leave it out I get an error
Engine traceback:
goal` `InvalidSetupPyArgs: Missing a
kwarg in the
field for libs/lib2:lib2. See https://www.pantsbuild.org/v2.15/docs/python-distributions.`
That sounds like a bug.
I will open an issue then, but I think there is already one https://github.com/pantsbuild/pants/issues/16360
So, I think you can route around the problem using the new support for
in BUILD files +
which is a bash file sourced for env var exports.
@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
target is provided, but the rule code still forces you to specify a manual version - that clearly makes no sense / does not integrate.
@cold-vr-15232 you'll need Pants 2.16.x, but the example use case for BUILD
is, in fact,
version: https://github.com/pantsbuild/pants/blob/main/docs/markdown/Using%20Pants/concepts/targets.md#environment-variables
Ok @cold-vr-15232,
does work as advertised but you must explicitly set
in your
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
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

$ cat BUILD.setup

    sources=["setup.cfg", "setup.py"],

$ 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
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
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.
I'm not sure the patch version bump is the right thing to do there either - that seems like a small bug as well.
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
@cold-vr-15232 and you have an opinion on that bump behavior, definitely speak up.
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.