-
Notifications
You must be signed in to change notification settings - Fork 988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for legacy register API #1627
Comments
I don't have a strong feeling one way or another. I disabled it because I didn't feel a need to implement it since it's not really required and ideally people register releases by uploading projects (this will become more explicit I hope in a Upload API 2.0 which will extract details from the files that get uploaded themselves instead of along side the file). That being said, none of my arguments against it are particularly compelling, the code to handle this is basically already written within the file upload API, that would just need to be extracted and generalized (one difference between file upload and register is that file upload only creates/updates the release if one doesn't exist, whereas register always creates/updates the release). As an aside, this doesn't really contribute to registered packages with no releases, since it still registers a release. If we want to get rid of that particular edge case we would need to either disallow deleting the last/only release of a project or implement it so that deleting the last/only release of a project implies deletion of the entire project. What this does enable though is for people to accidentally not upload their files but still seemingly get a release. A problem that will be less obvious in Warehouse since we purposely de-emphasize the list of files that have been uploaded by hiding them behind a tab. |
It might be worthwhile to poke distutils-sig to see if there is some major use case for the register functionality that I'm not remembering. |
I like this API for two reasons:
|
Chiming in to say that I consider this a required feature, since it lets you upload the draft metadata for your first release as soon as you have a package defined (e.g. https://pypi.python.org/pypi/leappto ), even if you don't consider it to be releasable yet. Without that, there's a potentially big time window between "good enough for GitHub" (where you're still just changing things arbitrarily without ever formally bumping the version number) and "good enough for PyPI" (where you've reached a point where you're happy to incur the additional overheads of actually pushing real releases to PyPI). Beyond that, there are also cases where you have a reasonable claim to a name (e.g. trademarks, popular project not available through PyPI, import package name actually installed as part of a different distribution package), and want to register it yourself to avoid potential conflicts (whether inadvertent or otherwise). |
Based on the discussion starting from pypa/packaging.python.org#271 (comment) I have an updated preference here: I now think
The fact that in Warehouse the Once the legacy service has been decommissioned and private index servers are also following the twine behaviour of doing all the work in If support for pre-registration were to be added back in at some future date, it would be as a new command (e.g. |
@dstufft raised the objection on the related PyPUG PR that silently doing nothing and then saying you did something is a major API design flaw, and while I agree in the general case, I think it's legitimate in this case due to the following:
Breaking the common case (register+upload) solely in order to make it easier to debug automation that is affected by a deliberately breaking change to the rare case (standalone register) seems like a bad design trade-off to me. There are also mitigations that could be put in place to attempt to alert people to their now-redundant use of
While 4 might be interesting long term, I think option 1 (the client-side warning) would be the most pragmatic of those options. |
Before we go one way or another here, I would be interested in what @sigmavirus24's opinion is on whether Warehouse should: A) Continue to not support the register API, meaning that My personal preference here is (A), and then maybe implement |
I'm going to close this, after talking it over with @sigmavirus24 and thinking about it, the path forward we're going to go is where we are now. Having the API removed in Warehouse with a possible enhancement of a pre-reservation API. |
For unknown reasons, this redirect is not honored during linkcheck. Signed-off-by: William Woodruff <[email protected]>
changelog: manually fixup index: fix link to pypi/warehouse#1627 For unknown reasons, this redirect is not honored during linkcheck. Signed-off-by: William Woodruff <[email protected]>
changelog: manually fixup index: fix link to pypi/warehouse#1627 For unknown reasons, this redirect is not honored during linkcheck. changelog: record missing #1194 and #1200. These did not have changelog files; I've written and imported them locally. Signed-off-by: William Woodruff <[email protected]>
Currently, the legacy API provided by Warehouse does not include the ability provided by pypi-legacy to register a package name, giving a "410 Client Error: This API is no longer supported" message.
Instead, it prefers to register the package the first time a release is uploaded. Thus, it's not actually necessary to register a package name at all before attempting to make an initial release.
There are a few open issues elsewhere as a result of this:
twine register
pypa/twine#200We currently have a stale PR which was attempting to add back the legacy register API: #1418
However, I see some advantages to continuing to not support this aspect of the API, namely because it's continued existence:
And in addition, as the current Warehouse API shows, it's seemingly unnecessary.
Should we add support for legacy-style registration?
The text was updated successfully, but these errors were encountered: