-
Notifications
You must be signed in to change notification settings - Fork 309
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
twine should not fail silently #92
Comments
What file? |
In this case it was wheel. |
No I mean what project, version, filename on PyPI. |
pygments-q, 0.5, pygments_q-0.5-py2.py3-none-any.whl. Note, that another owner was able to upload file without a problem. |
I see that file on https://pypi.python.org/pypi/pygments-q. Did you perhaps just check too soon before the Web UI cache was updated with the new version? |
It was uploaded from different project owner's account couple minutes later and it did show up there right away. For my username/password combination it silently failed. And I waited for 10-15 minutes for it to show up. |
Hmm. Strange. That would mean that PyPI accepted it but didn't save it somehow. |
Ok, I think I figured out what heppend:
Is this case supported? |
Ah. No it's not supported. I wonder if we should get rid of that redirect. |
It's better to update Python documentation, which pointed me to wrong server ;-) |
But still, if it is not supported, you should say so somehow in the error message. |
PyPI will never redirect a user during an upload. If a redirect is found, either the index URL is incorrect or there could be a malicious redirect at play. requests has well defined behaviour around handling POSTing data and what happens during a redirect. We shouldn't have to think too hard about that and there's probably a problem the user needs to handle if there is a redirect. Requests added 'is_redirect()' to Response objects in 2.3.0. In order to rely on that, we need to bump our minimum version. Closes #92
So I toyed with raising an exception in the case of a redirect but I'm not exactly sure it's the best idea. It would be pretty simple so long as we bump the minimum version of requests. I don't think anyone is using twine for anything other than PyPI, so it should be a relatively reliable way of preventing this kind of confusion. That said, a redirect to a different subdomain would cause requests to not attempt to post the body again, so the redirect like that won't ever be successful. I have pushed a branch with my rough approximation of what this would look like. https://github.com/pypa/twine/tree/bug/92 |
I like your change - that would have saved me an hour or so of my time today. :) |
PyPI will never redirect a user during an upload. If a redirect is found, either the index URL is incorrect or there could be a malicious redirect at play. requests has well defined behaviour around handling POSTing data and what happens during a redirect. We shouldn't have to think too hard about that and there's probably a problem the user needs to handle if there is a redirect. Requests added 'is_redirect()' to Response objects in 2.3.0. In order to rely on that, we need to bump our minimum version. Closes #92
I just experienced this issue, and @sigmavirus24's fix proposal looks better than everything I've come up with <3 |
PyPI will never redirect a user during an upload. If a redirect is found, either the index URL is incorrect or there could be a malicious redirect at play. requests has well defined behaviour around handling POSTing data and what happens during a redirect. We shouldn't have to think too hard about that and there's probably a problem the user needs to handle if there is a redirect. Requests added 'is_redirect()' to Response objects in 2.3.0. In order to rely on that, we need to bump our minimum version. Closes pypa#92
I've tried uploading package to pypi and it failed silently.
Twine reported, that file was uploaded, but actually file wasn't shown anywhere on pypi.
The text was updated successfully, but these errors were encountered: