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

Implement PEP 643 (Dynamic field for core metadata) #4698

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

abravalheri
Copy link
Contributor

@abravalheri abravalheri commented Oct 21, 2024

IMPORTANT: #4701 needs to be merged first, then this PR needs to be rebased (probably there will be conflicts). It might also be a good idea to wait until the next version of wheel is released (v0.45).

Summary of changes

This PR attempts to implement the 2nd approach suggested in #2685:

Mark everything as Dynamic if it comes from setup.py, but not if it comes from setup.cfg or pyproject.toml.

Values given via setup.py are considered dynamic for the sake of simplicity.

The "trick" implemented in this PR to avoid the problems with plugins/customisations described in #4629 (comment), is to mark static values instead of dynamic ones.

This marking is a bit "unconventional" (via subclasses of buit-in types), but it simplifies the tracking of changes and is backward compatible with the existing distutils/setuptools code base.

OPEN PROBLEM: wheel.metadata.pkginfo_to_metadata hardcodes Metadata-Version: 2.1.

Closes #2685

Pull Request Checklist

@abravalheri
Copy link
Contributor Author

@jaraco would this kind of approach be acceptable in setuptools?

@abravalheri abravalheri marked this pull request as ready for review November 20, 2024 17:37
Copy link
Member

@jaraco jaraco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't gone deep into the details, but at a high level, this change seems to honor the intentions of PEP 643.

It's not obvious to me what changes from a user's perspective. What projects are affected by this change? Does it simplify or complicate their experience? I think the answer is that projects largely don't have to do anything, but this change gives more fidelity to the metadata (at the cost of the added logic maintenance). If that's right, that seems like a fair tradeoff. Happy to give it a try. Let me know if there's a type of project you think I should run it against.

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 this pull request may close these issues.

[FR] Add support for PEP 643 - metadata for sdists
2 participants