Update package build and deploy

[bouweandela]

Description

• Update the package build and deploy GitHub Action using the latest example from https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
• Update the license information in pyproject.toml: https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-and-license-files
• Update the pins in the package build environment as recommended by setuptools-scm: https://pypi.org/project/setuptools-scm/
• Add a note about naming the release branch
• Add a note about approving the publish workflow

---

Before you get started

• ☝ Create an issue to discuss what you are going to do

Checklist

It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

• 🛠 This pull request has a descriptive title
• 🛠 Tests run successfully
• 🛠 The list of authors is up to date
• 🛠 Any changed dependencies have been added or removed correctly
• 🛠 All checks below this pull request were successful

---

To help with the number of pull requests:

• 🙏 We kindly ask you to review two other open pull requests in this repository

[bouweandela]

Upload to testpypi is failing because we use a local version (the version ends with + followed by g and the first digits of the commit hash) and that is not allowed. Apart from that, this seems to work fine. We could disable the local version, but I kind of like it because it allows distinguishing between development versions from different branches. Maybe we could just skip uploading to testpypi, as we do at the moment. Opinions @valeriupredoi?

[valeriupredoi]

Upload to testpypi is failing because we use a local version (the version ends with + followed by g and the first digits of the commit hash) and that is not allowed. Apart from that, this seems to work fine. We could disable the local version, but I kind of like it because it allows distinguishing between development versions from different branches. Maybe we could just skip uploading to testpypi, as we do at the moment. Opinions @valeriupredoi?

it's the dev53+gd85af0253 bit that PyPI doesn't like - no matter it be Test PyPI or the main PyPI - but why are you trying to upload to Test PyPI anyway, if the package builds well - and it does, then upload will work when it's time to release, unless, of course, there's something funky going on with the version. If you really want to test with Test PyPI, then chuck all this here on the v2.13 branch, that'll have a clean version 🍺

[valeriupredoi]

looks good, thanks, bud, reminds me I need to do the setuptools pins in a few places myself 🍺

EDIT: I see that now we have Publish: Test PyPI and Publish: main PyPI as two separate jobs - I'd deffo remove the Test job (comment it out so we can reactivate it if need be), it just adds extra guff since it will always be skipped

[bouweandela]

why are you trying to upload to Test PyPI

Because it looks like the packaging guide recommends it. I guess you could catch issues with forgetting to include certain files in the package if you would upload it to test pypi, install from there, and then run the tests, but since we haven't encountered any problems with this so far we may as well skip it.

[valeriupredoi]

why are you trying to upload to Test PyPI

Because it looks like the packaging guide recommends it. I guess you could catch issues with forgetting to include certain files in the package if you would upload it to test pypi, install from there, and then run the tests, but since we haven't encountered any problems with this so far we may as well skip it.

yeah that's good practice for newbies, we're all seasoned packagers here, bud. Cheers! Let me approve 🍺

[bouweandela]

I also enabled manual approval for the package upload step, as that is recommended for security reasons in https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#configuring-trusted-publishing

[valeriupredoi]

what's this for? That'll run on our mega latest v2.9.x from three years ago 😁
On a serious note, where's that manual approval enabled/configured, in the PyPI project settings?

[bouweandela]

what's this for?
To test that the package build works on the release branch.

That'll run on our mega latest v2.9.x from three years ago

Yes, but only if you would push a commit to it.

On a serious note, where's that manual approval enabled/configured, in the PyPI project settings?

https://github.com/ESMValGroup/ESMValTool/settings/environments/8132850576/edit

[valeriupredoi]

ah thanks, I also reckon that's a good idea 🍺