upload fail in middle with HTTPError: 400; This filename has already been used
#170
Comments
Borda
changed the title
HTTPError: 400; This filename has already been used
|
@Borda this is because files on PyPI are immutable. If you or somebody else uploaded an artifact with the same name in the past, you cannot reuse it. Even if you deleted it, even if it used to be someone else's project that got cleaned up and you got the PyPI project name. |
|
FWIW if you think there might be a bug, this would need to be reported to Warehouse and/or twine. cc @di @woodruffw @pquentin twine version has been updated in the action recently — are you aware of any possibility/reports of the upload process misbehaving? |
|
@di could you look into this on the PyPI side? There's no tarballs existing on the CDN it seems: $ curl -v https://files.pythonhosted.org/packages/source/t/torchmetrics/torchmetrics-1.0.0rc1.tar.gz 2>&1 | grep location:
< location: https://files.pythonhosted.org/packages/29/64/8507eb5eaee27b281ad71b4f4e90b2db50a5088d01f04eae77739a06976d/torchmetrics-1.0.0rc1.tar.gz
$ curl -v https://files.pythonhosted.org/packages/source/t/torchmetrics/torchmetrics-1.0.0.tar.gz 2>&1 | grep location:
$ curl -v https://files.pythonhosted.org/packages/source/t/torchmetrics/torchmetrics-1.0.1.tar.gz 2>&1 | grep location: |
|
This is the first such report I'm seeing, but note that this is using v1.8.7 which does not include #168. |
|
Ah, for some reason I thought this was the recent version of the action... |
|
Their last successful sdist upload was on Jun 29, it was v1.0.0rc1. Our action's v1.8.7 was released on Jun 26. So they're a chance that the working upload was using an older action version. But if not, this would make it a PyPI problem, not twine. |
|
In v1.8.7 the cryptography and requests pins were bumped. But since then, somebody else would also face this problem if it was related. The only Warehouse change that looks like it could be related is pypi/warehouse#14027 — it tightens the sdist filename validation. |
is this bump so critical?
yes we are aware of this
I personally created that project name two years ago and was most of the time the solo owner. if we used a version in the past and was removed I believe I would not be able to upload also wheel package, correct? |
Only if that version had a wheel. If the version in the past only had an sdist published, the problem would only manifest for sdists but not wheels since there's nothing to conflict with. |
interesting and could it be someone who owned the project name in the past, deleted it all and the name become available so could take it without any indication it was used in the past? |
Exactly. But I'd like to ask @di to verify this assumption. If that's the case, you'll probably hit similar problems in the future. |
No, but it bumps various packages, including a few major versions bumps so it might have introduced a bug. |
We have used this action version with other projects and everything of |
|
Looks like the successful upload of This further confirms my suspicion about somebody else having uploaded |
With the recent observations, I think we can exclude problems with version bumps and possible problems twine or this action... |
|
I wonder if the project got renamed to |
|
Alright, I've found their commit when they renamed the project. It's enochkan/torch-metrics@d78c61a#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7L4. |
|
I suppose the only way to know which versions can't be recycled is to ask @enochkan... |
|
@Borda one final piece of advice — switch to trusted publishing. It's not related to your current problem but is a good workflow upgrade — you'll be able to stop using the old-fashioned long-living API tokens. |
it was always This is quite challenging to users; you create a project which you think is new/unique without any warning, and suddenly you find many versions were already taken... shall there be some warning at least that you recycle the project name? |
could you please elaborate on what you mean, is this action not trusted? |
|
@webknjaz is referring to this: https://docs.pypi.org/trusted-publishers/ Trusted publishing is another way to authenticate and upload to PyPI, without using a username/password or a manually configured API token. The action itself is still trusted (and it's the same action as before), "trusted" in the context of "trusted publishing" refers to the fact that the CI platform (GitHub) is being trusted to obtain a temporary API token. |
Yes, this is what happened:
|
|
(I should mention that previous owners of this project name also uploaded |
|
I see, my security logs starts |
Hello, we have seen the same failed upload for the last two releases. We have built a package as a wheel and source and used
pypa/[email protected]to upload them to PyPI. First, it uploads the wheel, which passes, and the second source package fails in the middle. Also, this failed in middle yields that we can't re-upload the source package manually withtwine.See full action log:
1.0.0- https://github.com/Lightning-AI/torchmetrics/actions/runs/5462339923/jobs/99415738691.0.1- https://github.com/Lightning-AI/torchmetrics/actions/runs/5542425777/jobs/10117097368The text was updated successfully, but these errors were encountered: