Added a minimal release workflow.

[semohr]

This PR introduces a minimal release workflow that automatically publishes a new version to PyPI when a GitHub release is created.

Unlike the approach used in beets, where the release is triggered manually, this workflow opts for automation to keep things simple for now. While we may revisit and refine this logic later, this setup should be sufficient for our current needs.

Feedback and further ideas highly welcome!

[wisp3rwind]

Keeping this simple for now sounds reasonable 👍

Is it correct that we (or rather @sampsyo) haven't updated PyPi settings yet to authorize releases from this repo? It should be safe to merge this anyway, since it won't trigger until we attempt a release.

[wisp3rwind]

Maybe, it would be nice to already now:

• add a job that runs on each commit to main/PR and tests pushing to the PyPi staging environment: https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#separate-workflow-for-publishing-to-testpypi

• separate build and release steps to restrict permissions for the id token to only the latter; see the full example at https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#the-whole-ci-cd-workflow

[semohr]

Is it correct that we (or rather @sampsyo) haven't updated PyPi settings yet to authorize releases from this repo? It should be safe to merge this anyway, since it won't trigger until we attempt a release.

As far as I know that is correct. (Maybe the repo is already linked to pypi but I doubt it since the openid flow is relative new)

Maybe, it would be nice to already now: ...

Feel free to already push to this PR if you feel motivated. Otherwise I will have a look next week or over the weekend 👍