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

[warner]

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?

[sigmavirus24]

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

[warner]

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?

[sigmavirus24]

https://github.com/pypa/warehouse

[dstufft]

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

[sigmavirus24]

@dstufft did warehouse address this or no? Should I fix this for twine's next release?

[dstufft]

This has not yet changed in Warehouse. To be honest I forgot about it.

[sigmavirus24]

No worries. @dstufft would it help if I sent a PR to warehouse to implement this?

[dstufft]

Sure! It'd be in warehouse/forklift/legacy.py.

[hugovk]

I also hit this:

$ twine --version
twine version 1.8.1 (pkginfo: 1.4.1, requests: 2.12.4, setuptools: 32.3.1,
requests-toolbelt: 0.7.0, clint: 0.5.1)

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

$ twine upload dist/mypackage-1.7.0.tar.gz 
Uploading distributions to https://upload.pypi.org/legacy/
Uploading mypackage-1.7.0.tar.gz
[================================] 46592/46592 - 00:00:03

There are two places that say to register with twine:
https://packaging.python.org/distributing/#register-your-project
https://github.com/pypa/twine#usage

There's a stalled PR to update the former: pypa/packaging.python.org#271

It'd be great to update the latter too, to say what "if necessary" actually means.

[lanshark]

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

[trosel]

I'm following this tutorial: https://python-packaging.readthedocs.io/en/latest/minimal.html

Needless to say, I need some advice on how to proceed here. Why would they shut off the legacy upload system with no explanation or information?

edit: https://packaging.python.org/distributing/#working-in-development-mode That tutorial works for me. Not sure where the older one comes from.

[mcarans]

I also am lost. How do I register and upload on PyPI?

[sethmlarson]

@mcarans Just upload your package, register is not required any longer.

[alito]

Registering works on testpypi but not on the real pypi. Registering is useful if one is not able to upload the package (eg larger than PyPI's size limit), or is third-party hosting not supported on PyPI any more?

[johnyf]

@alito please see PEP 470 -- Removing External Hosting Support on PyPI.

[johnyf]

@lanshark if I understand correctly your comment about testing with testpypi as uploading to testpypi and then installing using pip and the package from testpypi, you can do:

twine upload upload -r test sdist/...
# trial installation
pip download \
    -i https://testpypi.python.org/pypi package_name
    --no-deps
pip install package_name-*.tar.gz

For uploading a package for the first time, I believe that you need to first register it on PyPI, either with twince register or manually.

[alito]

@johnyf ah, I see. Bummer. Thanks for the pointer

[lanshark]

@johnyf The problem with testing on testpypi is that the classifiers accepted in production and on testpypi are not the same. Specifically, django::1.10 is not defined on testpypi, but is defined on pypi. I would assume same for 1.11..

Those classifiers need to be kept in sync.

[johnyf]

@lanshark thanks for the clarification--I misunderstood the comment above by not realizing that it was about a Trove classifier, not about a dependency being present or not on the same index.

[tdicola]

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: #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.

[ndrplz]

Thank you @tdicola, after removing .pypirc file it finally worked!

[leycec]

This is horrible. As @tdicola suggests, the fatal error that twine currently emits appears to have nothing to do with the solution that most projects need to apply to resolve this error. In our case, our project doesn't contain a .pypirc file at all. We're unclear where to go from here to just get this to work – like it used to.

It used to work. It no longer works. Error messages are non-human-readable. Further confirmation that the Python packaging ecosystem remains fundamentally broken. </mega-frustrated>

[leycec]

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.

[george-silva]

For some reason, PyPi broke for a while and I had everything configured correctly. When it broke, (I did not know) it gave me the deprecation message and I was under the impressions it was necessary to configure the repo URL.

It is not. I can confirm @leycec solution.

[brainwane]

Thanks to @tdicola and others who have commented here and shared bug reports.

The newly improved Migrating to PyPI.org guide talks about the need to remove the [repository] line from a .pypirc, and the Test PyPI guide has .pypirc instructions too, which is good. But I'd also prefer for the tool to make life easier for the user by catching the old URL/setting and warning the user -- it's such a common case. So I've filed #307 which folks here might like to follow.

Thank you again and I'm sorry for the trouble.