Package Deployment

[rkaminsk]

There should be automatic package deployment.

pypi

Ideally, there would be a ready to use workflow that uploads packages to test.pypi (manually) and pypi (upon release).

conda

We might also want to upload to conda. However, since pypi packages can easily installed via pip into conda environments, we could skip such packages.

notes

For now, we might want to restrict attention to pure python packages.

[MaxOstrowski]

In favor for restricting it to python packages.
For pip it now got very simple to deplay on test.pypi.org and pypi.org.
An not fully finished example can be found here:
https://github.com/potassco/ngo/blob/main/.github/workflows/publish-to-pypi.yml

I would go for (maybe 2) github environments (that would need to be created manually) to protect the execution of the upload script. Furthermore, a tagging to v[0-9]+.[0-9]+.[0-9]+ should automatically trigger the process (and can require manual confirmation).

For handling of test.pypi.org I'm not so sure. I never really got the point of having test releases that fix bugs and would prefer to go to continuous releases on pypi.org directly? What do you think ?

[rkaminsk]

If I remember correctly, pypi does not provide any means to provide unstable releases. All users would get the latest development release by default. This info might be outdated. One of the main reasons to use test.pypi is to check if the release process works before actually releasing. Bugfix releases should of course go to pypi quickly.

[MaxOstrowski]

All users would get the latest release if they update their environment. If they want to fix it to a certain version, they can say so.
If we provide stable release scripts I do not necessarily see a reason to use test.pypi.org

Maybe this would be useful for development branches and unstable features, I do not have much experience with this usecase.

I don't think that clingo 5.7.0 is unstable (in terms of usage) for example.
But having a manually triggered CI script for test.pypi.org maybe doesn't hurt? It gives the developers a chance to deploy it this way if they like so...

[rkaminsk]

I admit I should have released clingo 5.7 already but this is not my point.

test.pypi is for testing the release process before uploading an actual release. This includes uploading test packages, installing them somewhere, and running them somewhere. This cannot be done with pypi because if anything goes wrong, the release would already be online. There is less that can go wrong with a pure python project but there are still some things that can go wrong.