I’d prefer to go with the key “tool”. It’s arguably less accurate (is an index server a “tool”?) but it reuses the familiar reserved name from pyproject.toml
.
Why wouldn’t we offer the data via HTML? I’m concerned that if we continue adding data to the JSON API without it being in the HTML API, we’re deprecating the HTML API by default, which was something PEP 691 explicitly said we weren’t doing. In PEP 700, I added some fields only to the JSON API, but at least I included a justification for that decision in the PEP (a justification I regret now, but that’s a separate point). I’d support deprecation of the HTML API as a PEP in its own right, but while we have it, I think the default should be to include new data in both APIs, and it should be necessary to justify excluding it, rather than needing a compelling reason to include it.
I’m a strong -1 on reverse DNS. Do we really want test.pypi.org to have a different metadata field than pypi.org? Do we want every instance of devpi or Artifactory to use its own namespace? Apart from the obvious redundancy, this would make using the data impossible, as consumers would have no idea what data was available based just on the namespace. Instead, I propose using the server implementation. I don’t want to be as strict as pyproject.toml
(we want PyPI to use the key pypi
, not warehouse
, IMO) but a flat namespace with server implementations claiming keys sensibly[1] seems perfectly workable. Mirrors need special consideration - it’s OK for a mirror to serve data for another implementation as long as that data is identical to the data on the base (so mirrors can’t “override” data locally) - but otherwise only the server implementation that owns the namespace is allowed to publish data in that namespace.
It’s worth stating that this scheme is implementable now, simply by using a _tool
namespace rather than tool
. Standardising how the “tool” namespace is managed is worthwhile, but ultimately not necessary.
One downside of not standardising the actual fields and their meanings is that I’d be reluctant for pip to warn on use of an “archived” project. Without a formal definition of what “archived” means and how it’s represented in standard metadata, we’d have to tie ourselves to implementation-defined details, and while PyPI is a special case, we thought for years that setuptools was a special case, and getting out of that assumption has been a massive undertaking
I’ll note though that as it stands, the pre-PEP here doesn’t actually define what “archived” means, even though it standardises how to represent that status. So I’d still be concerned about warning in pip - we’d be adding semantics that project maintainers might not want when they archive a project[2].