#19398 Wheel version numbers get strangely mutated by Pants Issue created by cbwl Describe the bug When packaging a wheel with Pants, the build of a wheel seems to be mutating the version number given in surprising ways. If the version number for a

python_artifact

is set to, for example,

0.0.1+foo.0123

, then the actual version produced will be

0.0.1+foo.123

-- i.e. the zero after "foo" will be lost. More information below. Pants version Version 2.16.0rc0 OS Tested on MacOS and Linux Additional info By way of exposition, take for example the following `python_distribution`:

python_distribution(
    name="test-dist",
    dependencies=[],
    provides=python_artifact(
        name="test-wheel",
        description="Let's see what happens to some build metadata",
        version=env("WHEEL_VERSION"),
    ),
    sdist=False,
)

If we build this with a value for

$WHEEL_VERSION

which is a SemVer containing both pre-release information and build metadata, the version numbers are preserved in the packaged wheel:

$ WHEEL_VERSION="0.0.1-prerelease.0123+buildmetadata.0456" pants package //:test-dist
16:19:12.31 [INFO] Wrote dist/test_wheel-0.0.1_prerelease.0123_buildmetadata.0456-py3-none-any.whl

$ unzip -p dist/test_wheel-0.0.1_prerelease.0123_buildmetadata.0456-py3-none-any.whl test_wheel-0.0.1_prerelease.0123_buildmetadata.0456.dist-info/METADATA | grep ^Version
Version: 0.0.1-prerelease.0123-buildmetadata.0456

This is surprising behaviour; the SemVer spec states about pre-release versions:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes.

... i.e. this version number is actually not valid SemVer because the

-prerelease.0123

should be rejected. Nonetheless, it's arguably not a bug per se because I don't think Pants necessarily promises that version numbers will be SemVer (maybe the Wheel spec says something about this?), so really Pants is just giving out whatever we put in. So be it. If we remove the pre-release portion of this and only retain the build metadata, things get more surprising:

$ WHEEL_VERSION="0.0.1+buildmetadata.0456" pants package //:test-dist
16:22:27.68 [INFO] Wrote dist/test_wheel-0.0.1+buildmetadata.456-py3-none-any.whl # Uh oh!

$ unzip -p dist/test_wheel-0.0.1+buildmetadata.456-py3-none-any.whl test_wheel-0.0.1+buildmetadata.456.dist-info/METADATA | grep ^Version
Version: 0.0.1+buildmetadata.456 # Uh oh!

Here, the leading zero has been stripped by Pants at some point in the packaging process, so Pants has not produced the version number that it was asked to. This behaviour definitely feels like a bug (note it's nothing to do with using

env()

to set the version number; I just did that for convenience of reproducing the issue). It's particularly surprising given that the SemVer spec says different things about build metadata from pre-release information:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. [....]

... i.e. there is no such stipulation that build metadata cannot start with a leading zero. pantsbuild/pants