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

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

Closed
warner opened this Issue Jul 21, 2016 · 25 comments

Comments

Projects
None yet
@warner

warner commented Jul 21, 2016

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

This comment has been minimized.

Member

sigmavirus24 commented Jul 21, 2016

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

This comment has been minimized.

warner commented 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?

@sigmavirus24

This comment has been minimized.

Member

sigmavirus24 commented Jul 21, 2016

@dstufft

This comment has been minimized.

Member

dstufft commented Jul 21, 2016

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

@sigmavirus24

This comment has been minimized.

Member

sigmavirus24 commented Aug 4, 2016

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

@dstufft

This comment has been minimized.

Member

dstufft commented Aug 4, 2016

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

@sigmavirus24

This comment has been minimized.

Member

sigmavirus24 commented Aug 4, 2016

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

@dstufft

This comment has been minimized.

Member

dstufft commented Aug 4, 2016

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

@hugovk

This comment has been minimized.

hugovk commented Jan 3, 2017

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/python-packaging-user-guide#271

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

@lanshark

This comment has been minimized.

lanshark commented Mar 15, 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...

@trosel

This comment has been minimized.

trosel commented Mar 17, 2017

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

This comment has been minimized.

mcarans commented Mar 29, 2017

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

@SethMichaelLarson

This comment has been minimized.

SethMichaelLarson commented Mar 29, 2017

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

@alito

This comment has been minimized.

alito commented Apr 9, 2017

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

This comment has been minimized.

@johnyf

This comment has been minimized.

johnyf commented Apr 12, 2017

@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

This comment has been minimized.

alito commented Apr 12, 2017

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

@lanshark

This comment has been minimized.

lanshark commented Apr 12, 2017

@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

This comment has been minimized.

johnyf commented Apr 12, 2017

@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

This comment has been minimized.

tdicola commented Nov 23, 2017

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

This comment has been minimized.

ndrplz commented Dec 8, 2017

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

@leycec

This comment has been minimized.

leycec commented Dec 19, 2017

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

This comment has been minimized.

leycec commented Dec 19, 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.

@george-silva

This comment has been minimized.

george-silva commented Jan 13, 2018

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

This comment has been minimized.

Member

brainwane commented Mar 1, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment