"ERROR InvalidDistribution: Invalid distribution metadata" for twine==6.1.0 but not twine==6.0.1

[LongerZrLong]

Is there an existing issue for this?

• I have searched the existing issues (open and closed), and could not find an existing issue

What keywords did you use to search existing issues?

ERROR InvalidDistribution: Invalid distribution metadata: license-expression introduced in metadata

What operating system are you using?

Linux

If you selected 'Other', describe your Operating System here

No response

What version of Python are you running?

$ python --version
Python 3.12.0

How did you install twine? Did you use your operating system's package manager or pip or something else?

pip install twine==6.1.0

What version of twine do you have installed (include the complete output)

$ twine --version
twine version 6.1.0 (keyring: 25.6.0, packaging: 25.0, requests: 2.32.4, requests-toolbelt: 1.0.0, urllib3:
2.5.0, id: 1.5.0)

Which package repository are you using?

pypi cloud

Please describe the issue that you are experiencing

When I download a whl from pypi with:

pip wheel --isolated --no-cache-dir --wheel-dir . execnet==2.1.1

Check the sha256sum of the whl:

$ sha256sum execnet-2.1.1-py3-none-any.whl
26dee51f1b80cebd6d0ca8e74dd8745419761d3bef34163928cbebbdc4749fdc  execnet-2.1.1-py3-none-any.whl

And upload it with twine:

twine upload execnet-2.1.1-py3-none-any.whl --verbose

I got the error:

ERROR    InvalidDistribution: Invalid distribution metadata: license-expression introduced in metadata version 2.4,
         not 2.3

Since it is a package downloaded from pypi, maybe there is an issue related to twine. Any information is greatly appreciated!

Please list the steps required to reproduce this behaviour

1. Install twine==6.1.0 in a virtual enviornment
2. Use pip to download the whl from official pypi:

pip wheel --isolated --no-cache-dir --wheel-dir . execnet==2.1.1

3. Check the sha256:

$ sha256sum execnet-2.1.1-py3-none-any.whl
26dee51f1b80cebd6d0ca8e74dd8745419761d3bef34163928cbebbdc4749fdc  execnet-2.1.1-py3-none-any.whl

4. Use twine to upload the whl:

twine upload execnet-2.1.1-py3-none-any.whl --verbose

And the error is reproduced.

Anything else you'd like to mention?

If I create a brand new virtual environment and install twine==6.0.1:

$ twine --version
twine version 6.0.1 (keyring: 25.6.0, pkginfo: 1.12.1.2, requests: 2.32.4, requests-toolbelt: 1.0.0, urllib3:
2.5.0)

Then it succeeds when uploading with this version of twine:

Uploading execnet-2.1.1-py3-none-any.whl
100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 47.6/47.6 kB • 00:00 • 325.1 MB/s
INFO     Response from http://10.105.206.126:32080/:
         200 OK

[woodruffw]

From inspector, the METADATA for this package looks invalid: it claims version 2.3 but includes License-Expression, which is only valid in 2.4 and newer.

I'm a bit murky on how this happened -- I would have expected PyPI to reject this wheel based on its metadata, plus the upload tooling should have also rejected it when it was sent to PyPI in the first place.

[woodruffw]

It looks like they use hatch/hatchling for their build backend, so I wonder if this is potentially a backend bug:

https://github.com/pytest-dev/execnet/blob/0ae3add1ec62c0349957385349bbd37382456460/pyproject.toml#L1-L6

Paging @ofek for thoughts 🙂

[ofek]

That's been fixed in Hatchling for a while, is the version pinned?

[woodruffw]

That's been fixed in Hatchling for a while, is the version pinned?

Hmm, doesn't look like it, but maybe there's some local caching at play?

https://github.com/pytest-dev/execnet/blob/0ae3add1ec62c0349957385349bbd37382456460/pyproject.toml#L1-L6

[ofek]

• 2.3: https://github.com/pypa/hatch/blob/hatchling-v1.27.0/backend/src/hatchling/metadata/spec.py#L460-L471
• 2.4: https://github.com/pypa/hatch/blob/hatchling-v1.27.0/backend/src/hatchling/metadata/spec.py#L546-L562

[woodruffw]

Ah, looks like execnet==2.1.1 was released on 2024-04-08, so prior to the fix (in hatchling==1.26.0).

Given that, there's probably not a ton for twine to do here -- the package's metadata is invalid, but the ecosystem as a whole is correctly strict about that.

@LongerZrLong could you provide some more details on what you're trying to accomplish here? Are you re-uploading execnet to a private index using twine?