Implement PEP 639: support for Metadata-Version: 2.4; Part I

[agriyakhetarpal]

Description

This PR implements PEP 0639 for make_wheels.py, which bumps the core metadata version from 2.1 to 2.4.

Here's a short summary of the changes that have been added:

• the 'License': 'MIT' (now deprecated) field has been changed to the favoured 'License-Expression': 'MIT' field, i.e., the SPDX identifier for the MIT License;
• License classifiers, while still common, have been deprecated: I removed the MIT license classifier in favour of compliance with the standard (in the above point), even though the deprecation cycle could be very long;
• The metadata is now not defined as a dictionary but as a list of tuples (the cleanest method I could find to implement without breaking or changing too much of the code), since we need to add multiple instances of the same key for 'License-File':. The multiple uses of this field include all of the licensing-related files I could find in the RECORD file that gets generated and re-checked manually in the source. There is a chance I might have missed a few, so, if you find any, please let me know!
• Added seven new classifiers to the project that I found are relevant enough to be included here, based on PyPI search related to them. If this is better to do as a follow-up PR, I'm happy to put up another.

I'll add additional information and context in a self-review below where I feel more context is needed, please let me know if I should add a few in-line comments in the code, too, for future references. Thank you!

[whitequark]

LGTM

[agriyakhetarpal]

This metadata version bump is backwards compatible. Please see https://peps.python.org/pep-0639/#backwards-compatibility for more. I tested recent versions of pip and uv, and they installed a wheel I generated for my M-series device without hiccups. I'll need to see if compliance with PyPI uploads is working, though, that's more important to figure out.

[agriyakhetarpal]

https://endoflife.date/python states that security releases for Python 3.7 have ended. Now that 3.13 is just around the corner, maybe we should update to a minimum of 3.8 (either here or as a separate PR). Please let me know.

[whitequark]

I'm aware of the EOL status of Python 3.5 (it was EOL when I wrote this package). I decided that this requirement should be bumped only if the package isn't installable/usable, since there isn't really a cost to keeping it low, and it could help someone using old Python versions.

[agriyakhetarpal]

Sure, makes sense!

[whitequark]

If we do change the launcher in such a way it stops working on earlier Python versions, we should support the last non-EOL version, of course.

zig-pypi/make_wheels.py

Lines 122 to 127 in f1cd7a9

	import os, sys
	argv = [os.path.join(os.path.dirname(__file__), "{entry_name}"), *sys.argv[1:]]
	if os.name == 'posix':
	os.execv(argv[0], argv)
	else:
	import subprocess; sys.exit(subprocess.call(argv))

[agriyakhetarpal]

I can't access a Python version that old unless I use actions/setup-python in a CI setup – and I remember that your previous mention in our earlier conversations of one to not become a maintenance burden. So we could leave it until someone asks; I doubt anyone will, though, since those Pythons are really old 😄

[whitequark]

Thanks!

[agriyakhetarpal]

Running twine --strict on a wheel currently fails:

❯ uvx twine check dist/ziglang-0.13.0-py3-none-macosx_12_0_arm64.whl --strict     

Checking dist/ziglang-0.13.0-py3-none-macosx_12_0_arm64.whl: ERROR    InvalidDistribution: Metadata is missing required fields: Name, Version.                                                                          
         Make sure the distribution includes the files where those fields are specified, and is using a supported Metadata-Version: 1.0, 1.1, 1.2, 2.0,    
         2.1, 2.2, 2.3.

I guess this might be because twine hasn't been updated yet, since the PEP was approved just last month, in August 2024. I'll take a deeper look, and if this would take time, maybe we should bump to just version 2.3 for now? 2.2 and 2.3 did not contain too many changes, and none of those are relevant for us here.

[agriyakhetarpal]

Oops, you merged too quickly, maybe! :D I'll open a new PR to fix any changes, though I would request not to upload any missing wheels with this.

[agriyakhetarpal]

Upstream issue: pypa/twine#1146

[agriyakhetarpal]

A fix should get merged soon: pypa/twine#1123

[whitequark]

I would request not to upload any missing wheels with this.

Noted.

[agriyakhetarpal]

pypi/warehouse#16949 has just been merged, and I've noticed a few issues with my implementation – I intend to fix them before uploading wheels can be ready. In particular, I see:

• there's an issue related to the file paths: the paths to the license files are supposed to be relative to the source folder (ziglang/ in this case) – from https://peps.python.org/pep-0639/#add-license-file-field

This is easy to fix, of course.

• Copying from the PEP: "if the Metadata-Version is 2.4 or greater and one or more License-File fields is specified, the .dist-info directory MUST contain a licenses subdirectory, which MUST contain the files listed in the License-File fields in the METADATA file at their respective paths relative to the licenses directory."

This is something I didn't implement at the time; looks like other backends are doing so in parts, too: pypa/setuptools#4728. What I don't understand about this is that the Zig source in the wheels should remain unchanged, so I'm supposed to move but copy the relevant license files that I added in this PR. But isn't that just going to create duplicate files? I feel that's a limitation of the PEP, because it doesn't cover this case (where multiple licenses are going to be present across subfolders). The other option is to just copy the MIT (Expat) license file for this project (which would be the more usual approach) and add a note about the licensing for the bundled Zig source in the README. Do you have any thoughts?

I'll validate the changes with updated versions of twine and packaging and with whatever APIs are available to perform said validation.

[whitequark]

But isn't that just going to create duplicate files?

That's fine. The archive isn't winning any size competition anyway, and text compresses well.