need more specific diagnoses/error messages when uploading/registering

[MikeHart85]

After further conversation below, this issue is now focused on:

• When something goes wrong, you should provide a specific error message, not just disconnect with no explanation.
• The exact same failure should not produce different error codes / messages depending on whether you're registering or uploading, or whether you're uploading a tarball or a wheel.

---

This isn't a very useful error message... unless it's really just a random disconnect, which it isn't here.

Potentially related to:
pypi/warehouse#2533
pypi/legacy#675
pypa/twine#263

I was getting much the same behaviour. Turned out to be caused by a tiny detail in setup.py in my case.

Using twine register on any package or twine upload dist/* would return 499 Client Error: Client Disconnected every time after a bit of delay. In the case of twine upload, it even appeared to upload but then failed after reaching 100%.

Then I tried uploading specifically the .tar.gz instead of dist/* (which defaulted to attempting .whl first):
$ twine upload dist/project.tar.gz

Tries to upload .tar.gz
[Progress bar appears, hangs on 5%, jumps to 100%, hangs, and then...]
HTTPError: 400 Client Error: author_email: Invalid email address.

That's different!(?!)

Our author_email field has always followed a "Some Name <some.name@e.mail>, Other Name <...>, ..." format to list multiple authors. This has always worked fine in the past. Because of that last error, I tried changing it to simply: author_email="my.name@e.mail". Suddenly, everything works again:

$ twine upload dist/*
Uploading distributions to https://upload.pypi.org/legacy/
Uploading project.whl
Uploading project.tar.gz

Thoughts on this:

• The format of author_email should not be a failure condition. It's just a string with some meta information.
• When something goes wrong, you should provide a specific error message, not just disconnect with no explanation.
• The exact same failure should not produce different error codes / messages depending on whether you're registering or uploading, or whether you're uploading a tarball or a wheel.
• Why does twine register exist, especially now that it's not necessary / doesn't work?
• Does twine really need to exist? Why not simply pip upload? Or an upload button on the website?

I don't think this is the exact issue @s-m-e is having, since the author_emailin his project is just a single email. But it could be some other detail in his setup.py isn't formatted right, or maybe it's something else entirely. It's hard to tell how related the issues are... because this isn't a very useful error message.

[merwok]

Author-Email accepts many forms, but only one value: https://www.python.org/dev/peps/pep-0345/#author-email-optional

(I agree on your other points about developer experience)

[di]

@MikeHart85 You are correct, PyPI was being overly restrictive with the author_email field, this was fixed in pypi/warehouse#2904.

[MikeHart85]

@di Cool, thank you!

[brainwane]

@MikeHart85 Just to double-check -- now that this is addressed in Warehouse, shall we talk about the other related points you brought up?

On whether twine should exist: pypa/twine#154 and #60 and pypa/twine#127 ask this too, and eventually the vision is for twine to merge with pip so people won't have to use two separate tools.

We've removed twine register which is now reflected in the twine README.

[ncoghlan]

@brainwane Adding publication capabilities to pip is far from being an agreed proposal, since it's like saying "I should be able to use my eReader to publish new books as well downloading and reading existing ones".

Publishing & maintaining new libraries is a very different activity from installing and using existing ones, and has a correspondingly steeper learning curve.

[brainwane]

Thanks, @ncoghlan - I was going off an older comment by Donald that I took as a decision that had already been made. Other folks who want to take a look at that conversation: it's ongoing in #60.

@MikeHart85 Since we've addressed some of the concerns you brought up and are addressing others elsewhere, I'm taking the liberty of changing the title and prepending a problem restatement on this issue. Thanks.