Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support for legacy register API #1627
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:
We 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?
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.
referenced this issue
Apr 10, 2017
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/python-packaging-user-guide#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