Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License info no longer included in METADATA #1804

Closed
cdce8p opened this issue Nov 12, 2024 · 6 comments · Fixed by #1805
Closed

License info no longer included in METADATA #1804

cdce8p opened this issue Nov 12, 2024 · 6 comments · Fixed by #1805

Comments

@cdce8p
Copy link

cdce8p commented Nov 12, 2024

A few projects I know have started to adopt the new project.license syntax recommended in the docs https://hatch.pypa.io/1.9/config/metadata/#license. With hatchling==1.25.0 this would include a License-Expression key in the METADATA file.

This was change in #1790 + #1792 and now these project neither include License-Expression nor the "old" License key meaning the license information (which is specified correctly) is just lost.

I understand that technically License-Expression is only added with metadata version 2.4 which isn't supported by PyPI yet. However, it's fine to still include it in older versions as well (it will just get ignored by PyPI and not be validated on upload). The isn't a big issue though as hatchling already validates it.

If that's not an option, might I recommend to backfill the License key with the SPDX expression instead (temporarily). That would be equivalent to using the "old" syntax with text project = {text = "MIT"}. I don't think it makes much sense for projects to revert back to the old syntax themselves only to change it again once support for PyPI lands.

@ofek
Copy link
Collaborator

ofek commented Nov 12, 2024

That's not true actually, PyPI hard rejects such uploads which is why I pushed the fix over the weekend #1786

@cdce8p
Copy link
Author

cdce8p commented Nov 12, 2024

That's not true actually, PyPI hard rejects such uploads which is why I pushed the fix over the weekend #1786

Interesting 🤔 I've definitely seen projects which for which the upload with License-Expression worked. Seems to be a side effect of the added validation in packaging 24.2 that it now also checks the field against the metadata version.

Would the backfill to the License field make sense? The PR for PyPI seems to be ready but I'm not sure how long it will take until it's actually merged. pypi/warehouse#16949

@ofek
Copy link
Collaborator

ofek commented Nov 12, 2024

I'm not exactly against the backfill idea but are you able to wait <2 weeks until that is merged? One of the maintainers said that it would be merged "in the next week or so".

@cdce8p
Copy link
Author

cdce8p commented Nov 12, 2024

Just saw #1805. Thanks a lot!

That's not true actually, PyPI hard rejects such uploads which is why I pushed the fix over the weekend #1786

I tried to reproduce it today, just because I'm involved with the setuptools implementation of PEP 639, but couldn't. The upload to PyPI even with License-Expression, License-File and Metadata-Version: 2.3 worked fine for me. Not sure what caused #1786.

Setuptools (currently) includes a non-spec version of License-File and I haven't seen any issues for that either.

@cdce8p
Copy link
Author

cdce8p commented Nov 12, 2024

That's not true actually, PyPI hard rejects such uploads which is why I pushed the fix over the weekend #1786

I tried to reproduce it today, just because I'm involved with the setuptools implementation of PEP 639, but couldn't. The upload to PyPI even with License-Expression, License-File and Metadata-Version: 2.3 worked fine for me. Not sure what caused #1786.

To be clear. It fails the metadata validation with packaging==24.2 but that doesn't seem to be deployed to (all) PyPI servers yet ..?

@ofek
Copy link
Collaborator

ofek commented Nov 13, 2024

deployed to (all) PyPI servers yet

Oh good point! The rollout might be gradual which would explain the inconsistent error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants