twine: "410 Client Error: This API is no longer supported" during `twine register`

I upgraded to twine-1.7.4, then did a twine register dist/foolscap-0.12.0.tar.gz, and got the following error message:

% twine register dist/foolscap-0.12.0.tar.gz
Registering package to https://upload.pypi.io/legacy/
Registering foolscap-0.12.0.tar.gz
HTTPError: 410 Client Error: This API is no longer supported, instead simply upload the file. for url: https://upload.pypi.io/legacy/

I couldn’t really figure out what I was doing wrong, so I downgraded to the twine-1.6.5 I’d had previously, and then twine register and twine upload worked fine.

Is this user error, or something internal going wrong?

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 26
Comments: 25 (9 by maintainers)

Commits related to this issue

Remove pypi `register` No longer necessary / possible https://github.com/pypa/twine/issues/200 — committed to n8henrie/cookiecutter-pypackage by n8henrie 7 years ago

Most upvoted comments

Yea, though perhaps we should just continue to allow registration separately, even if it’s not needed.

dstufft on Jul 21, 2016

Ah, got it. Maybe we could update the server’s message to include some of that text… “With pypi.io, the ‘register’ API is no longer necessary: please just use ‘upload’ instead”, and maybe with a URL that points to a longer explanation?

I could work on a patch for that. What’s the repo for the server codebase?

warner on Jul 21, 2016

I’m following all the instructions for uploading to pypi and running into this error too (instructions from here: https://packaging.python.org/tutorials/distributing-packages/#uploading-your-project-to-pypi). I dunno what to say other than to just echo sentiment that this is super confusing and a huge hurdle for publishing python packages. Shouldn’t ‘twine upload dist/*’ just work? I dunno what is going wrong here, I’m not choosing some legacy endpoint and am using the latest twine 1.9.1 version:

tony-imac:mpy tony$ twine upload dist/*
Uploading distributions to https://pypi.python.org/pypi
Note: you are uploading to the old upload URL. It's recommended to use the new URL "https://upload.pypi.org/legacy/" or to leave the URL unspecified and allow twine to choose.
Uploading adafruit-ampy-1.0.3.tar.gz
HTTPError: 410 Client Error: Gone (This API has been deprecated and removed from legacy PyPI in favor of using the APIs available in the new PyPI.org implementation of PyPI (located at https://pypi.org/). For more information about migrating your use of this API to PyPI.org, please see https://packaging.python.org/guides/migrating-to-pypi-org/#uploading. For more information about the sunsetting of this API, please see https://mail.python.org/pipermail/distutils-sig/2017-June/030766.html) for url: https://pypi.python.org/pypi

Just posting this comment as venting/frustration that this is much, much harder and confusing than it should be IMHO. Not sure how to fix it…

edit: So here’s the magic incantation to fix it for folks that run into this and are as completely perplexed as I was: https://github.com/pypa/twine/issues/270 The key is to comment out any [repository] setting you had in .pypirc. After doing that it seems to work and upload again. It would be really, really nice for twine to catch this case and give an actionable error since previous packaging instructions told people to add that repository line, etc.

tdicola on Nov 23, 2017

OK, problem: I tried to register, and got the 410 error telling me to just upload. So, I run upload, and get a 403 Client Error: you are not allowed to upload. Of course, in the twine README (usage, above) it says:

If you see the following error while uploading to PyPI, it probably means you need to register (see step 2):

$ HTTPError: 403 Client Error: You are not allowed to edit ‘xyz’ package information

SO, how, exactly, is one supposed to upload a new package (brand new, never been distributed before) these days? I have .pypirc pointed at upload.pypi.org/legacy/.

AND, I can’t test it on testpypi, because it uses the Django 1.10 framework classifier, which is NOT on testpypi, but is on production…

lanshark on Mar 15, 2017

Oh. Right. It’s 5:15AM on a bitter December morning, which means I’m stupid. .pypirc lives at ~/.pypirc rather than in our project’s root directory. ^{…of course it does}

For the comment-tolerant, here’s mine (excluding authentication tokens, obviously):

# --------------------( SYNOPSIS                           )--------------------
# PyPI configuration file. For convenience, authentication credentials for both
# the live ("pypi") and test ("pypitest") versions of PyPI.
  
# ....................{ MAIN                               }....................
# List of arbitrary labels for all enabled PyPI index servers. For each such
# label, a corresponding configuration section *MUST* be defined below.
[distutils]
index-servers =
  pypi
  testpypi

# ....................{ REPOSITORIES                       }....................
# Live version of PyPI.
#
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# CAUTION: The "repository" key must *NOT* be defined for the standard PyPI API,
# as the underlying URL changes too frequently to warrant inlining here.
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[pypi]
username=
password=

# Test version of PyPI.
[testpypi]
repository=https://testpypi.python.org/pypi
username=
password=

And that’s how the cheeseshop was won.

Incidentally, this is why you do not break longstanding API URLs. Lookin’ at you, PyPI.

leycec on Dec 19, 2017

Twine 1.7 switched the default PyPI URL to pypi.io. This is the next generation of PyPI and far more reliable and stable than pypi.python.org currently is. On the new version of PyPI, register is unnecessary. @dstufft can explain in more detail

sigmavirus24 on Jul 21, 2016