Status or funding for Metadata 2.2+ in PyPI

I’m starting this thread to understand the current status of Metadata 2.2+ (primarily for sdist) in PyPI. I’ve got 3 questions.

What is the current status and blockers for broad support?

Is there work planned for it?

Would it be possible to accelerate it with any funding and would that be welcomed?

1 Like

What precisely do you mean by “Metadata 2.0”? There was a spec with that name but it got withdrawn. If you mean 2.2 (PEP 643) then it’s blocked on implementation by PyPI - the PR is Metadata 2.2 and 2.3 by konstin · Pull Request #13606 · pypi/warehouse · GitHub. As far as I know, that’s only waiting on reviewers from the Warehouse team, so it’s blocked on them.

As far as accelerating it is concerned, that’s just the well known issue of “how do we get more resource for PyPI?” and I don’t know the answer to that one.

3 Likes

Doh! Yes, I meant 2.2 thanks! I wish Withdrawn PEPs had a banner or something to more easily notice it. Haha!

I’ve fixed the title.

Thanks for the link to the PyPI PR. It looks promising.

After PyPI supports the newer Metadata versions, there is still more to be done for the ecosystem to utilize it right?

Whats does the roadmap look like?

Build (and publishing?) tools need to produce the new metadata?

Resolvers/Installers need to make use of it where it is available?

Is there anything else?

That’s basically it, I think. I guess it’s possible that PyPI will publish the metadata for sdists as separate files so that consumers can avoid downloading the full sdist, but I’m not sure how important that is (sdists are typically a lot smaller than wheels, aren’t they?)

I don’t know that there’s any sort of “roadmap” as such. It’s more about dependencies - backends can’t produce metadata 2.2 until PyPI allows it to be uploaded, and it’s pointless for installers to add support for it until there’s some on PyPI to justify doing so. Individual projects will work on support once it’s possible for them to do so, and when they have resources to do the work.

1 Like

So the ordering is:

  • PyPI
  • Build Backends
  • Installers

What’s the best source to measure availability of newer Metadata versions once PyPI and build backends support it?

If you want to track when that happens, feel welcome to subscribe to…

… or even file a PR to make that actually happen! :slight_smile:

Not quite. Installers can implement support before PyPI and build backends.

1 Like

True. I guess until there’s an incentive or very clear evidence that its available, I think many would be reluctant to eagerly implement it? I don’t know of any that support it yet? The closest that I found on the pip tracker was this Implement PEP 643 to optimise `pip download --no-binary` · Issue #10195 · pypa/pip · GitHub

If PEP 643 was accepted in Oct/Nov 2020 (~3 years ago) and the PyPI PR was started in May 2023 (~1 year ago), it doesn’t seem like any installers will be in a rush to implement anything ahead of time.

I’m very excited! Hatchling has supported 2.2 and 2.3 for about 2 years as an option and I’d like to upgrade the default which is currently 2.1.

1 Like

Awesome!

For my own clarity, since you mentioned hatchling and not hatch, am I understand you to mean from the Build Backend perspective? Not from the Installer perspective right?

Hatch simply uses pip for installation (and soon optionally UV).

1 Like

Thanks for clarifying. That was my understanding of Hatch v hatchling too, but wanted to confirm.

So that’s good. It means soon (hopefully) there will be PyPI support and at least one Build Backend.

A major one would be setuptools, which has an existing issue [FR] Add support for PEP 643 - metadata for sdists · Issue #2685 · pypa/setuptools · GitHub

Good news!

Looks like the PyPI support has been merged!

I’m not exactly sure if this means that it’s been deployed to the live site yet.

5 Likes

PyPI auto deploys anything on main that passes tests, since there’s no gating of this feature, unless the deployment failed it should be live.

2 Likes

So good!

Huge thanks to you and all the other maintainers and contributors on warehouse for keeping things running smoothly and moving forward! :muscle:

3 Likes

:tada:

I’ve uploaded a test package using metadata 2.3, pyo3-mixed 2.1.5, to both testpypi and pypi: PKG-INFO. The next maturin release should write fully static metadata 2.3 for all source distributions and wheels (PyO3/maturin#1965).

5 Likes

How does this affect private indices? For example, if I now make the default 2.3 in Hatchling would that break uploads of private packages?

I’ll probably do it anyway if it does, just curious.

I’m not sure if any indexes other than PyPI actually read the metadata version and reject versions they don’t know about. If they do, then yes, they should have been updated to allow version 2.2+. I’d hope that they’ve done this by now, though - the delays for PyPI are pretty unusual. And if they haven’t, they probably won’t until users start reporting that valid packages are getting rejected :wink:

6 Likes

Looks like after a small false start with twine → pkginfo (Check command doesn't recognize metadata 2.3 · Issue #1059 · pypa/twine · GitHub)

Maturin looks like it’s the first Build Backend defaulting to Metadata 2.3 :tada:

Thanks @konstin

4 Likes

Hmmm… it’s a bit of a race now isn’t it? If installers/resolvers like pip, poetry, uv etc don’t install or understand the newer Metadata, projects won’t want to publish the newer Metadata…