Automatically build and upload PyPI packages on release

[dralley]

Using Github Actions

This will build and upload both source and binary Python packages automatically every time a new release is published. The binary packages should enable Python users to use libcomps across any (linux) platform without needing the compile-time dependencies needed by Python source distributions.

We (current maintainers of the PyPI libcomps package) will need to add your PyPI account as a maintainer, and then you will need to add your credentials to the github repo secrets. Afterwards it should be automated and we will ensure it continues working if any problems arise in the future.

Here's a snapshot of using the binary package built on Centos 7 on a clean Debian VM with pip 20 (older versions can't use the binary package)

vagrant@debian10:~/devel/community/libcomps$ python3 -m pip --version
pip 20.0.2 from /home/vagrant/.local/lib/python3.7/site-packages/pip (python 3.7)
vagrant@debian10:~/devel/community/libcomps$ python3 -m pip install wheelhouse/libcomps-0.1.14.post1-cp37-cp37m-manylinux2014_x86_64.whl 
Defaulting to user installation because normal site-packages is not writeable
Processing ./wheelhouse/libcomps-0.1.14.post1-cp37-cp37m-manylinux2014_x86_64.whl
Installing collected packages: libcomps
Successfully installed libcomps-0.1.14.post1
vagrant@debian10:~/devel/community/libcomps$ cd libcomps/src/python/tests/
vagrant@debian10:~/devel/community/libcomps/libcomps/src/python/tests$ python3 -m pytest __test.py 
============================================================================================================ test session starts =============================================================================================================
platform linux -- Python 3.7.3, pytest-5.3.5, py-1.8.1, pluggy-0.13.1
rootdir: /home/vagrant/devel/community/libcomps
collected 82 items                                                                                                                                                                                                                           

__test.py ..................................................................................                                                                                                                                           [100%]

============================================================================================================= 82 passed in 0.73s =============================================================================================================
vagrant@debian10:~/devel/community/libcomps/libcomps/src/python/tests$ 

[dralley]

If you're not interested in this, let me know and I can just close the PRs.

[lukash]

@dralley I'm planning to attempt to set this up in the next few days, sorry about the long silence.

[dralley]

@lukash I have added building documentation and running the C tests with check to the CI

[lukash]

One more thing, could you name the workflows ci-python.yml and release-python.yml? I've renamed the createrepo_c one, for consistency.

[dralley]

@lukash This is great! Yes, I can update the PR.

[lukash]

Ah, also: I assume this is still WIP because of the __TOKEN__ placeholder. Just a heads-up, it seems you are using this PR branch for testing, which is generating quite a lot of spam mail. Could you possibly test on a different branch and push here when finished? :grin: Cheers!

[dralley]

@lukash Apologies for the spam! It might be configurable, because we're also using Github Actions in our org and I don't get spammed by everyone else's failed PR runs.

Re: __token__, apparently that is how it's actually supposed to be done. I agree, it's awkward and "feels" wrong.

https://packaging.python.org/specifications/pypirc/#using-a-pypi-token

[lukash]

@lukash Apologies for the spam! It might be configurable, because we're also using Github Actions in our org and I don't get spammed by everyone else's failed PR runs.

I didn't mean the spam of the failed workflow runs, just the spam of repeatedly force-pushing to the branch. I don't want to turn off those notifications, I use them.

IMO people should only create PRs when the code is ready to be reviewed and same for updating PRs. If you push your WIPs, besides spamming it's actually not clear when your PR is ready for a review (I don't want to review WIP unless explicitly asked for feedback on it). Just my PoV, not sure how others see this.

Re: __token__, apparently that is how it's actually supposed to be done. I agree, it's awkward and "feels" wrong.

https://packaging.python.org/specifications/pypirc/#using-a-pypi-token

Oh, that's actually not terrible, so the __TOKEN__ basically tells it the password is a token, sorry, I just missed that!

[dralley]

IMO people should only create PRs when the code is ready to be reviewed and same for updating PRs. If you push your WIPs, besides spamming it's actually not clear when your PR is ready for a review (I don't want to review WIP unless explicitly asked for feedback on it). Just my PoV, not sure how others see this.

I understand. In this case, I was just testing the release CI (temporarily changed the trigger to "pull_request" in order to do so). Both PRs are reviewable at the present moment.

[lukash]

@dralley I just force-pushed your master :grimacing: hope it's ok. I made a few cosmetic adjustments, as well as renaming the PYPI_API_TOKEN secret and changed the Python CI to run on pull_request only (same as I did on createrepo_c). Let's see how it works, we'll need to keep an eye on the release workflow once we actually do a release, libcomps is released very infrequently.