Closed bluenote10 closed 1 month ago
In #142 it has been suggested to use twine for publishing the project.
In my case, publish attempts were failing with requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://upload.pypi.org/legacy/
. I tried everything, upgrading tools, resetting upload tokens, using a proxy server, etc. I had no clue that there was already a successful release uploaded. I finally tried twine
in --verbose
mode and it showed me the underlying error:
INFO Response from https://upload.pypi.org/legacy/:
400 Bad Request
INFO <html>
<head>
<title>400 File already exists. See https://pypi.org/help/#file-name-reuse for more information.</title>
</head>
<body>
<h1>400 File already exists. See https://pypi.org/help/#file-name-reuse for more information.</h1>
The server could not comply with the request since it is either malformed or otherwise incorrect.<br/><br/>
File already exists. See https://pypi.org/help/#file-name-reuse for more information.
</body>
</html>
ERROR HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/
Bad Request
Thanks for pointing to #142. It looks like this issue is actually a duplicate of it, so I would close this issue.
I'm new to flit, so maybe I'm just missing something, but it would be nice to have an option to tolerate an existing published version on PyPI.
Motivation
I use this CI pattern with my other (non flit) Python packages: On a push to the main branch, the corresponding GitHub Action runs the PyPI upload with a
skip_existing: true
setting. This is pretty nice, becauseSo far I haven't found how to replicate this mode with flit. Currently my publish pipeline fails with
requests.exceptions.HTTPError: 400 Client Error: File already exists.
when I haven't bumped the version.I'm also not a big fan of the other common solution (https://github.com/pypa/flit/issues/276#issuecomment-699096070) of running the publish pipeline only when a tag was pushed, because maintaining git version tags violates the single-source-of-truth of the version information.
I'd be curious if there are other common solutions?
Possible solution
If not, it would be nice to have
flit publish --skip-existing
. The implementation could be e.g.:File already exists
response an accepted case (this would have the maximum coverage of the publish procedure).