CI Auto-deploy wheel and source distribution to pypi on release

[drewejohnson]

When we make a tag or a release, we need to then upload something to pypi so people can install with pip install --upgrade serpentTools

It would be beneficial and more efficient if github could perform this automatically for us for new tags. There are a few things to consider

1. Running specific github actions for tags, not pushes to main / pull requests - github docs might be helpful
2. Build wheel with pip wheel --no-deps . to create serpentTools-TAG-py3-none-any.whl
3. Upload that to pypi using twine

Some caveats / things to look out for

setuptools_scm

I'm not sure how the tag will get propagated into the action, and we need the tag to work with setuptools_scm version setting - #500. There's the ability to force a version with environment variables SETUPTOOLS_SCM_PRETEND_VERSION or SETUPTOOLS_SCM_PRETEND_VERSION_FOR_serpentTools. If one of these environment variables are present in the job, and set to the tag name (maybe exposed from github?) the wheel should have the correct version

pypi authentication

It's recommended to use api tokens to upload to pypi with twine. But, we must not expose this token in any file tracked in this repository. Otherwise, someone could pull the token and upload a fake version to pypi.

I think there's a way to do this with github actions secrets, where the api token for pypi could be added to the project (maybe via settings or security?) and then exposed to the action. Then, we could do something like

twine upload --username __token__ --password ${SERPENT_TOOLS_TWINE_API_TOKEN} serpentTools-0.11.0.whl

the .whl wheel file is a made up name, and same with the environment variable SERPENT_TOOLS_TWINE_API_TOKEN. But something like that could be exposed to the workflow.

We'd also want to make sure that that token is not exposed to any other jobs, nor printed in any jobs, so that it doesn't leak out.

• https://pypi.org/help/#publishing
• https://pypi.org/help/#apitoken
• https://docs.github.com/en/actions/security-guides/encrypted-secrets
• https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment

[drewejohnson]

This could complicate conda installs #385 because we don't have a setup.py file with setuptools to do python setup.py sdist and create and upload a source dist to pypi. This is what was used in some preliminary conda build tests, where the builder would pull a source distribution from pypi. It might work with a wheel file though, since we just need something to pass to pip for building, and pip can build from wheels too