don't remove the ability to get package versions via the JSON API

[dimbleby]

#11777 marked the "releases" key deprecated.

This would be painful in poetry, which uses that part of the API to determine the available versions of a package.

Per python-poetry/poetry#6076 (comment), I think a sensible API and poetry's needs are aligned here:

• it makes perfect sense to remove most of the information in releases, clients that need all of the details for a particular version can go to the version-specific endpoint (and this is indeed what poetry does)
• but removing the capability even to learn what the available versions are seems like overshoot

perhaps it would make sense to replace "releases" with eg "versions", listing the available versions.

NB parsing the simple API (even in json form) is a less satisfactory approach for poetry. Eg consider a package like cryptography, for which there are maybe a couple of dozen downloads available at each release: to get the available versions poetry would have to iterate over each of those files and parse their names - rather than simply reading the answer. Clearly this is much less efficient.

[dstufft]

I don't have any conceptual reason not to add a versions field to this API.

However, I do just want to point out that I think that parsing the filenames not being as efficient is not entirely accurate.

The legacy JSON API has a ton of extra data inside of it, including the full long description of the project, which has a theoretically unbounded length (and for some projects appear to be approaching 7MB just from the long description alone). You can't state that "simply reading the answer" is more efficient, without first accounting for the fact that you've already wasted time and bandwidth downloading potentially large amounts of data that you're not even using.

Overall, I'd prefer that we look at iterating on the simple API for features that installers need, as that's our golden path here. But I don't think it would be rejected if someone were to write a PR to add a versions key to the legacy json API.

[dimbleby]

I've no objection to limiting either the amount of data that is allowed to be in a description or the amount of data that is returned in a description; nor to the simple API being made more useful for installers.

I see your hint re a PR - thanks - not sure that I'm likely to get to it in the very near future but it could happen. Clues as to where the relevant code is certainly welcome anyway, whether for my benefit or someone else's.

[emcd]

Adding to the comments of @dimbleby:

• Package names do not always match the PyPI project name that provides them. This is not an issue with the legacy JSON API, but would potentially be an added complication for code parsing the results from the Simple API.
• Iteratively parsing the list of package files from the Simple API to match a package version raises the barrier to entry for someone writing a package manager, package version lock manager, etc.... (As someone who has written a package version lock manager in the past year, I will say that tracking various PEPs and pieces of PyPA documentation that may or may not be out-of-date introduces enough cognitive burden for someone, who isn't in the thick of the Python packaging world, as it is. Not intended to be a slight or criticism of anyone or any project, but there is a non-trivial amount of scattered information to absorb and form into a coherent picture.)

But, yes, I also would be quite content to see the Simple API made more useful for installers / lock managers / etc....

[dstufft]

The simple API now includes an array that lists all of the versions of a project, which I believe removes the concern over using the simple API for getting this information (AIUI, the concern is that parsing filenames is less efficient than just getting a list of versions from the service).

I'm going to close this issue (and the related PR, sorry I never got around to reviewing it, the pandemic ruined my ability to focus and this fell off my plate) with the expectation that the simple API should suffice now for this use case.