Unlisted releases are useful to preview how a release looks before it is discoverable by the general public.
Example:
You would check the “Unlisted releases” checkbox in the project settings page. Then, all new releases would be unlisted. They can be explicitly requested, but are not discoverable. When they are ready for public consumption, they can be changed in the Releases tab.
Assuming release 1.8 is “unlisted”, https://pypi.org/project/test would show the page for 1.7. Release history would show 1.7 as the latest release. However, 1.8 could be accessed explicitly: https://pypi.org/project/test/1.8.
pip install test would install 1.7, however, 1.8 would be installable if specified explicitly: pip install test==1.8.
Note: PEP 694 (draft) defines a similar feature that “stages” a release, however it would only work if its new upload API (2.0) is used. The “Unlisted releases” checkbox setting would work for any upload API.
Can’t you achieve the same result by publishing beta (or alpha or rc) releases? You can also publish to test.pypi.org
I agree, that would also be possible. The motivation for this post was to provide a simpler alternative for the “stage” feature in the draft PEP 694. I had the idea after I finished reading the PEP 694: Upload 2.0 API for Python Package Repositories thread.
Any such proposal would need to describe how it would affect the simple index API and if it made changes to the API how tools consuming those changes should behave.
I’ll note that from the API perspective this sounds very similar to yanked packages, that are not expected to be consumed unless directly pinned. Unless you intend for them to be available only via the PyPI UI and not to tools consuming the API.
