GeezerVison

'Fixed a bug by removing the feature', you might say!

I think the converse is true here, peps.json isn't really an 'API', but just a document listing the metadata from the PEP headers in a slightly easier to use format than RFC (2)822 email headers. As such I think it has better symmetry with peps.rss, which is also at the root. It does no harm to keep both, and I think we should resolve the fact that one isn't documented.

A

'Fixed a bug by removing the feature', you might say!

:)

Well, this bug/feature was added in a large-ish refactoring PR (#3417) which made no mention of the addition in the description, and was merged 10 minutes later with no review.

I only realised this duplicate endpoint existed when #4226 was opened yesterday, and would have objected to the addition at the time, as we had a long discussion at #2584 about whether to move it to the root, and in the end decided not to.

I think the converse is true here, peps.json isn't really an 'API', but just a document listing the metadata from the PEP headers in a slightly easier to use format than RFC (2)822 email headers. As such I think it has better symmetry with peps.rss, which is also at the root.

I see it as a simple read-only JSON API, much like https://endoflife.date/docs/api, https://swapi.dev and https://open-meteo.com.

It does no harm to keep both, and I think we should resolve the fact that one isn't documented.

I think it can cause confusion to have two copies. Are they different? Will one go away? If we change one, will the other also change? If we start versioning it, do we need to add another duplicate to the root? Or if we expose JSON for each individual PEP, do they all go to the root?