test pypi upload fails (using legacy?)

[KrisThielemans]

PETSIRD/.github/workflows/test_pypi.yml

Line 48 in fd6b833

twine upload --repository-url https://test.pypi.org/legacy/ dist/* -u __token__ -p ${{ secrets.TEST_PYPI_TOKEN }}

Actions reports

Uploading petsird-0.0.1-py3-none-any.whl
25l
  0% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 0.0/43.8 kB • --:-- • ?
100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.8/43.8 kB • 00:00 • 152.6 MB/s
100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.8/43.8 kB • 00:00 • 152.6 MB/s
100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.8/43.8 kB • 00:00 • 152.6 MB/s
100% ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 43.8/43.8 kB • 00:00 • 152.6 MB/s
25hWARNING  Error during upload. Retry with the --verbose option for more details. 
ERROR    HTTPError: 400 Bad Request from https://test.pypi.org/legacy/          
         Bad Request                                                            
Error: Process completed with exit code 1.

@casperdcl @lukepolson suggestions?

[casperdcl]

probably because 0.0.1 already exists?

[KrisThielemans]

#40 still has the same problem. Could be because 0.0.1 exists of course, I have no idea.

[lukepolson]

Yes, it's probably because 0.0.1 already exists. For testpypi you can delete packages:

https://stackoverflow.com/questions/47915527/how-to-do-i-delete-edit-a-package-and-its-release-file-list-in-test-pypi-org

but as far as I understand, you cannot on the official pypi. This means we need to be very careful everytime the GitHub action is called, since it will not push to pypi if there is already a version of that number

[casperdcl]

You can yank, but you can't clobber packages (on both PyPI servers).

I'll implement the normal buildnum work-around... though tbh i feel GH build artefacts are much better for this usecase.

[lukepolson]

Ah I see, thanks for clarifying @casperdcl ; I'm still quite new to this!

[KrisThielemans]

I'm a little bit lost here (of course).

The TestPyPi upload CI was essentially to test if we could upload to Pypi later. My guess is that #42 serves a different purpose: people can download the very latest version from there, and presumably do some pip install whatever to directly install from there. Correct? If so, that's a great thing to have (as long as we document it).

Aside from this, obviously at some point it'd be nice to upload to PyPi itself. At that point, we do need to be careful about versions, which we are not yet. It's not so clear to me if the current set-up would already be enough to upload to PyPi, or if we need other work in our CI file to make this only happen if we tag.

[casperdcl]

Ha there's no need to test PyPI infrastructure. I'd be more worried about checking this package itself.

Uploads to PyPI do already work as-is on semver tag pushes; no tokens/passwords needed.

#42 does indeed allow downloading & pip installing locally.

[KrisThielemans]

ok. Feel free to merge #42. just to confirm:

• if we semver tag, the current action will upload to pypi.
• how do we pip install from the artefact?

[casperdcl]

if we semver tag, the current action will upload to pypi

Yes

how do we pip install from the artefact?

Download & extract it to get the *.whl file which you can pip install /path/to/whl