-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Update to Metadata 2.3 to create reliable source dist metadata #1965
Conversation
✅ Deploy Preview for maturin-guide ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I suppose pypi/warehouse#13606 has already been deployed to pypi production?
Yes, i uploaded pyo3-mixed 2.1.5 with metadata 2.3: https://inspector.pypi.io/project/pyo3-mixed/2.1.5/packages/2b/b8/e04b783d3569d5b61b1dcdfda683ac2e3617340539aecd0f099fbade0b4a/pyo3_mixed-2.1.5.tar.gz/pyo3_mixed-2.1.5/PKG-INFO |
Twine issue for the ci failure: pypa/twine#1059 |
Source distributions contain a `PKG-INFO` file at root level with metadata in the same format as wheel metadata. Unlike wheel metadata, this file was previously unreliably, the metadata did not need to (and often did not) match the metadata of the built wheel. [PEP 643](https://peps.python.org/pep-0643/) introduces Metadata 2.2, where fields can either be static (default) or marked as dynamic. When a source distribution uses `Metadata-Version: 2.3` in its PKG-INFO file, all static fields in the source distribution metadata must match the metadata of a built wheel ([spec](https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-format)). This means that e.g. when requirements and extras are not marked as dynamic, a version resolver can read the metadata directly from the source dist without a PEP 517 invocation. This is both a huge speedup and makes python packaging more reliable. This PR bumps the metadata version maturin uses to 2.3 ([PEP 685](https://peps.python.org/pep-0685/) – Comparison of extra names for optional distribution dependencies). It does not add support for dynamic, instead maturin writes static metadata for all of its source dists. If possible, i'd like to keep maturin to emit purely static metadata, it has advantages both for the python packaging ecosystem and by enforcing a better project structure. If you want a single source of truth for the package version, i recommend storing the version in pyproject.toml `project.version` and using `importlib.metadata.version` in the python code. I bump the version to 1.5.0 since it's a significant behaviour change, but doesn't justify a 2.0 release.
d62f284
to
9d26d20
Compare
Source distributions contain a
PKG-INFO
file at root level with metadata in the same format as wheel metadata. Unlike wheel metadata, this file was previously unreliably, the metadata did not need to (and often did not) match the metadata of the built wheel.PEP 643 introduces Metadata 2.2, where fields can either be static (default) or marked as dynamic. When a source distribution uses
Metadata-Version: 2.3
in its PKG-INFO file, all static fields in the source distribution metadata must match the metadata of a built wheel (spec). This means that e.g. when requirements and extras are not marked as dynamic, a version resolver can read the metadata directly from the source dist without a PEP 517 invocation. This is both a huge speedup and makes python packaging more reliable.This PR bumps the metadata version maturin uses to 2.3 (PEP 685 – Comparison of extra names for optional distribution dependencies). It does not add support for dynamic, instead maturin writes static metadata for all of its source dists. If possible, i'd like to keep maturin to emit purely static metadata, it has advantages both for the python packaging ecosystem and by enforcing a better project structure. If you want a single source of truth for the package version, i recommend storing the version in pyproject.toml
project.version
and usingimportlib.metadata.version
in the python code.I bump the version to 1.5.0 since it's a significant behaviour change, but doesn't justify a 2.0 release.