Add 'Implement metadata PEPs'

[pfmoore]

What is the current situation/context? PEPs 643 and 658 have been agreed but are not yet implemented in key projects.

What ought to be fixed, made, or implemented? Implementing these PEPs into warehouse and setuptools would enable consumers to start relying on static metadata being available.

What problems would this solve, and what new capabilities would it cause? Currently tools either have to download distribution files to access metadata, or they infer critical metadata (like project name) from filenames which use normalised names, losing information about the un-normalised project name.

What kinds of work are necessary to make this happen? Development work in Python (for setuptools) and for server-side tasks (for warehouse)

[di]

Thanks for this Paul.

Does PEP 658 still make sense to implement given PEP 691 exists (and directly addresses PEP 658-style metadata?)

[pfmoore]

As standards, both are accepted, so they still apply. But the question here is around implementing them in Warehouse.

I'd be happy enough if Warehouse implemented the part of PEP 658 that states that metadata will be extracted from the project files and made available on the index server, and served that information in the PEP 691 index. I'd be surprised if omitting it from the simple index were a huge saving, so I don't see the point in not implementing it there as well, but I could be wrong, and I'm happy for that decision to be up to the warehouse maintainers. I was assuming, though, that as part of supporting PEP 643, the metadata served up in the index (whether via PEP 658 or PEP 691) would include both sdist and wheel metadata.

Having said all of this, scoping the work will probably depend on what funding is achieved, so budget will affect this as well.

On a personal note, my priorities are:

1. Be able to get wheel metadata without downloading the wheels.
2. Be able to upload sdists containing metadata 2.2.
3. Support metadata 2.2 in setuptools (and other build backends, but setuptools is, I believe, the only one where the problem is hard and so needs funding). Specifically, ensure that sdists contain static metadata for name, version, python-requires and dependencies for as many cases as possible, as that's what pip needs for the resolver. Dependencies will be the hard one there, unless the setuptools team is willing to deprecate setting them in setup.py (as opposed to a static file).
4. Be able to get sdist metadata without downloading the sdists.

But I'm happy if the funded work includes a "work out priorities by surveying the user base" task, and doesn't just take my preferences as definitive 😉

[pfmoore]

Can this be merged, please? I think it's an important piece of work that could do with at least being a visible option for sponsors looking for things to fund.