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

Support Metadata Version 2.2 #9660

Closed
uranusjr opened this issue Jun 12, 2021 · 6 comments · Fixed by #13606
Closed

Support Metadata Version 2.2 #9660

uranusjr opened this issue Jun 12, 2021 · 6 comments · Fixed by #13606

Comments

@uranusjr
Copy link
Contributor

What's the problem this feature will solve?
Since PEP 643 is accepted, PyPI should start accepting Metadata 2.2 distributions. See PyO3/maturin#564.

Describe the solution you'd like
Allow Metadata-Version: 2.2 to pass the legacy upload endpoint’s form validation, and validate the corresponding Dynamic field.

The latter part could be a bit tricky since Dynamic is not allowed for wheels. Not sure how it could be best handled (I don’t have much experience with WTForm).

Additional context
https://www.python.org/dev/peps/pep-0643/

@di
Copy link
Member

di commented Feb 16, 2022

There's a couple levels of 'validation' that could happen for the Dynamic field here:

  1. Validate that Name and Version are not marked as Dynamic (feasible)
  2. Validate that wheels do not set Dynamic (probably feasible)
  3. Validation across multiple artifacts (probably infeasible):
    • If a field is not marked as Dynamic, then the value of the field in any wheel built from the sdist MUST match the value in the sdist. If the field is not in the sdist, and not marked as Dynamic, then it MUST NOT be present in the wheel.
    • If a field is marked as Dynamic, it may contain any valid value in a wheel built from the sdist (including not being present at all).
    • Backends MUST NOT mark a field as Dynamic if they can determine that it was generated from data that will not change at build time.

Are we OK with only doing 1 & 2? (cc @pfmoore)

@konstin
Copy link
Contributor

konstin commented Feb 16, 2022

From my perspective just allowing 2.2 when no Dynamic is used would already be great and solve PyO3/maturin#564

@pfmoore
Copy link
Contributor

pfmoore commented Feb 17, 2022

I think (1) is reasonable. The PEP allows wheels to set Dynamic, so I think (2) is wrong, and should be omitted. I'm happy that Warehouse shouldn't try to do (3).

@di
Copy link
Member

di commented Feb 17, 2022

The PEP allows wheels to set Dynamic, so I think (2) is wrong, and should be omitted.

Got it. I was taking this from the original issue and thought I was missing something in the PEP. I'll update the OP accordingly.

If all we need to do is 1) then this is straightforward.

@domdfcoding
Copy link
Contributor

What's the next step for this? Is it just waiting on a PR?

@di
Copy link
Member

di commented May 14, 2022

Yes.

valgur added a commit to valgur/velodyne_decoder that referenced this issue Feb 26, 2024
scikit-build-core set the metadata version to 2.2 that is not yet supported by PyPI.

This was due to a dynamic pyproject.toml section being used.
pypi/warehouse#9660
valgur added a commit to valgur/velodyne_decoder that referenced this issue Feb 26, 2024
scikit-build-core set the metadata version to 2.2 that is not yet supported by PyPI.

This was due to a dynamic pyproject.toml section being used.
pypi/warehouse#9660
@di di closed this as completed in #13606 Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants