make `register` error (with PyPI) more informative

[brainwane]

I may be missing something, but if the core mission for Twine is publishing on PyPI, and twine register (per pypi/warehouse#1267) is a no-op, I think we should deprecate and then remove the user-invocable register command.

I propose we deprecate it in the upcoming version (1.10) and then remove it in 1.11.0.

So, in 1.10.0:

• mark Repository.register() and twine/commands/register.py as deprecated with @deprecated decorators
• add a ..deprecated:: marker to the register guidance in the README

In 1.11.0:

• remove Repository.register() and twine/commands/register.py
• remove register from the list of commands in setup.py
• remove the PackageNotFound exception from twine/exceptions.py
• update the README, the architectural overview in docs/contributing.rst, and the changelog

[sigmavirus24]

I'm not sure we can remove register. I think there are package indices that still require registration before upload like devpi. Some folks use twine with that iirc and I'm not sure what indices buildout is using twine to interact with.

[jamadden]

My group isn't using devpi yet (so I can't verify whether devpi needs register), but we expect to soon. It would be a shame if twine didn't work with it, I imagine we'd like to keep most of our normal workflows which involve twine and/or zest.releaser (which uses twine under the covers).

[brainwane]

Thanks for the pushback. I see where I fundamentally went wrong was

the core mission for Twine is publishing on PyPI

I think this clarifies for me that we have three goals.

1. User-facing tool for publishing on pypi.org
2. User-facing tool for publishing on other Python package indexes (e.g., devpi instances)
3. Useful API for other programs (e.g., zest.releaser) to call for publishing on any Python package index

So here's my new proposal:

1. Add that explanation to the README and the architectural overview.
2. Add relevant context to twine register usage help.
3. If someone gets a "PyPI doesn't need you to register anymore" error, maybe they're pushing to PyPI and need the "no longer necessary" error, OR, maybe they've forgotten the repository URL they mean to be pushing to, which is a package index that does require registration. Make the error more informative.
4. Add relevant context via code comments in Repository.register() and twine/commands/register.py.
5. Update setuptools and distutils docs, e.g., https://docs.python.org/3.6/distutils/packageindex.html#the-upload-command and https://setuptools.readthedocs.io/en/latest/setuptools.html#using-setuptools-without-bundling-it , to clarify that PyPI does not require register anymore but other package indexes might.
6. Start a discussion on distutils-sig, and possibly a draft PEP that updates PEP 301, about upload APIs for Python package indexes, with particular attention to the existing Warehouse API and to register functionality.

1-4 sound faster; 5 and 6 sound harder and slower.

[brainwane]

There's now a bugs.python.org issue open to update the distutils docs regarding register.

[brainwane]

@hpk42 mentioned to me in #devpi earlier this month that devpi does not require registration. @mplanchard does pypiserver ever need registration?

[mplanchard]

@brainwane nope!

• to be more detailed, we support the command, but it is not required

[brainwane]

@fschulze says that devpi does still currently need the register call.

[bhrutledge]

@brainwane With the merge of #457, do you have more thoughts on resolving this issue?

[brainwane]

A lot has been done for this issue but these are the things that, I think, still need doing:

• If someone gets a "PyPI doesn't need you to register anymore" error, maybe they're pushing to PyPI and need the "no longer necessary" error, OR, maybe they've forgotten the repository URL they mean to be pushing to, which is a package index that does require registration. Make the error more informative.
• Add relevant context via code comments in Repository.register() and twine/commands/register.py.

And, ideally (but this issue does not have to block on this):

• Start a discussion on distutils-sig, and possibly a draft PEP that updates PEP 301, about upload APIs for Python package indexes, with particular attention to the existing Warehouse API and to register functionality.