CDpypi

[MaxOstrowski]

Add continuous deployment on [test.]pypi.org

[rkaminsk]

Is there any reason to use reusable workflows here? To me it looks like they should fit into one workflow (consisting of multiple jobs). We could parametrize the publishing workflows because they are structurally equivalent. I also have a (messy) example here: https://github.com/potassco/clingo/blob/master/.github/workflows/cibuildwheel.yml. One can have jobs with dependencies.

At the very least only the "Build Wheel and source tarball" should be reusable.

Furthermore, I would, at least for the release workflow, add a version check. The git version tag and the one in setup.cfg should be identical. This will prevent trivially botched releases. We could even use setuptools-scm to extract the version from the git tag. Unfortunately, I do not see a way to do this nicely for the workflow publishing to test.pypi.

In principle, one would not even need multiple jobs because everything can run on the same container.

[MaxOstrowski]

Is there any disadvantage of having reusable workflows? I thought it might be easier to extend and maintain (e.g. adding conda, etc...) But I don't have a strong opinion about it. This is the first time I use reusables.

The version check sounds like a useful thing to have. I don't think that the behvaiour for test.pypi.org should be different, no ? You can't overwrite versions there too, no ?

[rkaminsk]

Is there any disadvantage of having reusable workflows? I thought it might be easier to extend and maintain (e.g. adding conda, etc...) But I don't have a strong opinion about it. This is the first time I use reusables.

The version check sounds like a useful thing to have. I don't think that the behvaiour for test.pypi.org should be different, no ? You can't overwrite versions there too, no ?

I find it easier to read everything in one file as long as the file stays short enough. By simply using one job one also needs to start just one container. Deployment will be faster. In clingo, I used multiple jobs because packages had to be build on multiple hosts.

The main advantage of reusable workflows is when there is sharing between different workflows. Here we should be able to set up things in away that this is not needed. I'll try to work on this next. Probably, in a small test project using this template that I can deploy to test.pypi. I'll keep you in the loop.

[rkaminsk]

The deployment section still needs cleanup.

[rkaminsk]

I was exploring a bit how setuptools_scm can help us to ease the deployment process.

The current state is here and I am actually quite satisfied with it. Please have a look at the links below:

• https://github.com/rkaminsk/fuzzy-waddle
• https://test.pypi.org/project/fuzzy-waddle/

To summarize, I did the following:

• merged setup.cfg into pyproject.toml because the latter seems to be the thing
• the deployment process is in deploy.yml which
  • automatically deploys to pypi.org (url still has to be changed) when pushing a version tag
    • the version will automatically be extracted from the tag
  • can be used to manually deploy to test.pypi
    • the version will automatically be extracted from the last version tag
    • a .devN suffix will be added where N is the number of commits since the last version tag

Max's proposal was using a reusable workflow to run the tests before the deployment. This can easily be added back. Just let me know what you prefer.

[rkaminsk]

@MaxOstrowski: let's continue from #31