Skip to content
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

Closed
di opened this issue Dec 29, 2016 · 8 comments
Closed

Support for legacy register API #1627

di opened this issue Dec 29, 2016 · 8 comments

Comments

@di
Copy link
Member

di commented Dec 29, 2016

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:

  • Enables name squatting;
  • Creates the edge case of how to display a registered package with no release (404 for registered package with no release #1388);
  • Causes the occasional support request to release an unmaintained package with no releases.

And in addition, as the current Warehouse API shows, it's seemingly unnecessary.

Should we add support for legacy-style registration?

@dstufft
Copy link
Member

dstufft commented Dec 29, 2016

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.

@dstufft
Copy link
Member

dstufft commented Dec 29, 2016

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.

@kennethreitz
Copy link

I like this API for two reasons:

  1. Name squatting :)
  2. Fixing RST easily.

@dstufft dstufft added this to the 1: Launch: redirect pypi.python.org to pypi.io milestone Jan 24, 2017
@ncoghlan
Copy link
Contributor

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).

@ncoghlan
Copy link
Contributor

Based on the discussion starting from pypa/packaging.python.org#271 (comment) I have an updated preference here: I now think
twine register should be emulated as a no-op in Warehouse, specifically so that the following sequence of commands works the same way with both service implementations:

twine register ...
twine upload ...

The fact that in Warehouse the register is a no-op and all the work takes place in upload would then be a service implementation detail, rather than the externally visible client-breaking API discrepancy that it is now.

Once the legacy service has been decommissioned and private index servers are also following the twine behaviour of doing all the work in upload, then client scripts can start dropping the now redundant register step.

If support for pre-registration were to be added back in at some future date, it would be as a new command (e.g. twine reserve, as suggested by @dstufft), and come with related changes to the data model that allowed projects to have a provisional existence independent of any particular release.

@ncoghlan
Copy link
Contributor

@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:

  • in the twine register && twine upload case, folks won't even notice the difference, since the requested work just moves around between the steps, rather than the total work changing
  • for the standalone twine register case, folks checking for their registration on PyPI will still see that the registration didn't happen, even though twine claimed it worked. That means the error report is a debugging aid, rather than the sole indication that something unexpected may have happened.

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 register through other means:

  1. Add a warning that the command is now redundant to the twine client, rather than trying to provide the warning/error from the server
  2. Send users an email when standalone register is used. Their automation won't break, but they'll potentially spam themselves.
  3. Add a notification somewhere in the maintainer UI. Awkward, since my understanding is that many of those pages aren't in Warehouse yet, so folks instead use the legacy service, and folks with automated package management may never look at those pages anyway.
  4. Add a fortnightly opt-out "Your PyPI projects" status report, and use it to notify people when their automation is using deprecated endpoints like register

While 4 might be interesting long term, I think option 1 (the client-side warning) would be the most pragmatic of those options.

@dstufft
Copy link
Member

dstufft commented May 29, 2017

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 twine register will always be broken on Warehouse (suggesting it should probable be deprecated and removed).
B) Support it as a no-op, which will make the command appear to work, but not actually do anything.
C) Just fully support it even though I think it is a bad feature and would rather not have it continue existing, possibly deprecating it in the future (for more discussion, view pypa/packaging.python.org#271 (comment)).

My personal preference here is (A), and then maybe implement twine reserve at some point, however I wanted to poke @sigmavirus24 because since he's maintaining twine, he's getting (and is likely to continue to get) most of the support requests for people confused by this issue.

@dstufft
Copy link
Member

dstufft commented Jun 3, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants