[Bug]: HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/

[vws100]

Describe the bug

@marcusr2ML @skilledwolf
v3.0 release triggered a build under ALPS Python Packaging CI/CD that threw an error in fetching from pypi:

https://github.com/ALPSim/ALPS/actions/runs/35013232569/job/104560690572#logs

To Reproduce

Check the log

https://github.com/ALPSim/ALPS/actions/runs/35013232569/job/104560690572#logs

Expected behavior

Everything in .github/workflows/build_wheels.yml should work

Environment (please complete the following information)

- OS: [e.g. Windows10, macOS Monterey]
- Python version: [e.g. 3.8.1]
- Related module versions if applicable: [e.g. numpy=1.23.5]

Additional context

No response

[egull]

The actual packaging failure is run 35013232569. Its cause is clear:

The release tag is v3.0.0.
But pyproject.toml at that tag still declares version = "2.3.4b1".
Consequently, the workflow built files named pyalps-2.3.4b1-….
Those filenames were already uploaded to PyPI’s existing 2.3.4b1 release.
PyPI does not allow an existing distribution filename to be replaced, so it returned:
400 File already exists (pyalps-2.3.4b1-cp310-cp310-macosx_15_0_arm64.whl)

So the build itself largely succeeded; publishing failed because the Python-package version was never changed to match the new release.

The proper recovery is to update pyproject.toml to the intended Python version—presumably 3.0.0—commit that change, and publish from a new corrected tag. Simply rerunning the existing workflow will fail again. Setting skip-existing: true would hide the collision, but it would still publish under the incorrect 2.3.4b1 version and therefore is not the right release fix.

[skilledwolf]

The python wheels are on PyPI now. I also added Python 3.14 wheels. Merging PR #143 will prevent this problem from happening on future releases.