Marc Mueller

@ofek Would you mind taking a quick look at this one? I believe it would improve the documentation around `project.license` and `project.license-files`.

A new release would be great. Testing with 3.14 is currently blocked for us since https://github.com/pyca/pynacl/pull/848 isn't released yet. We're already at `b2`, only a few months until the release...

> [@cdce8p](https://github.com/cdce8p) can you break down what we can help with to make this happen? [This one](https://github.com/python/cpython/issues/118803)? The fix is already part of main, so all that's needed here AFAICT...

@dnicolodi Is right here. The `License-File` metadata generated by setuptools causes an error during validation with `packaging==24.2` since the metadata version isn't `>=2.4`. This hasn't been an issue so far...

> I was thinking that twine/PyPI/pip have been accepting `License-File` with metadata version 2.2 for a while. PyPI uses `packaging.metadata` to validate the submitted form fields. Unknown fields are just...

> > PyPI uses `packaging.metadata` to validate the submitted form fields. Unknown fields are just ignored. With `24.2` `license_files` was defined as being added in `2.4` thus it would start...

_One last post from me and then I'll shut up and respect your decision :)_ > we need to move very carefully to avoid breaking the ecosystem all at once....

> I think this is the only way to proceed as pre PEP 639 and post PEP 639 license declaration formats are not compatible with each other, thus emitting metadata...

> However, with this approach, having packages with PEP 639 license metadata will require two releases of the packages involved: one that updated the metadata fields in `pyproject.toml` to the...

> I wasn't involved in that decision, either, but I believe it was ill-advised. Even if the situation with license information was a problem, adding fields not defined in the...