Closed KrisThielemans closed 19 hours ago
probably because 0.0.1 already exists?
Yes, it's probably because 0.0.1 already exists. For testpypi you can delete packages:
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
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.
Ah I see, thanks for clarifying @casperdcl ; I'm still quite new to this!
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.
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.
pip install
ing locally.ok. Feel free to merge #42. just to confirm:
pip install
from the artefact?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
https://github.com/ETSInitiative/PETSIRD/blob/fd6b833d85169937d25e504f5e822571f1ace136/.github/workflows/test_pypi.yml#L48
Actions reports
@casperdcl @lukepolson suggestions?