adopt setuptools-scm for auto versioning

[bjlittle]

🚀 Pull Request

Description

This PR adopts setuptools-scm to automate the versioning of iris.

This means that we no longer need to care about bumping the iris.__version__ manually for a release, or post-release to a dev version.

Requires #4840 to be merged first, in order to include the relevant updates to the requirements yml and lock files.

Also, once this is merged, we're then in a position to automate the routine creation, testing and publishing of iris source and binary PyPI wheels, as a GHA. See #4849.

Reference: See setuptools-scm.

TODO:

• Update the developer documentation
• Include re-rendered conda-lock files
  • Include py310 requirements (Support python 3.10 #4840)
  • Include Lockfile update and Gregorian to Standard calendar change #4847
• Fix docs version parsing
• Demonstrate auto versioning on tagging a release (on @bjlittle/iris forked repo)

  1. Add git@github.com:bjlittle/iris.git as a git remote
  2. Then git checkout the (bjlittle/iris) v3.3.0 tag, see https://github.com/bjlittle/iris/releases/tag/v3.3.0
  3. Within an activated "iris-dev" conda environment, "pip install -e ."
  4. Check the version, with either of the following commands:
     a. python -c 'import iris; print(f"{iris.__version__}")'
     b. python setup.py --version (if "setuptools-scm" is installed)
  

---

Consult Iris pull request check list

Nice @bjlittle
But I had one slight concern : will this affect our release version numbering scheme?
E.G. I'm rather hoping we don't get auto-generated date-stamped release versions, in place of manual tagging

@pp-mo No, this won't affect our release version numbering scheme. Business as usual.

For example,

• a clean development version will be something like 3.2.2.dev158 (where the last offical release was the patch 3.2.1)
• an uncommitted development version will be something like 3.2.2.dev158+dirty

When we tag the release in GH, the tag name will automatically become the iris version.

I'll confirm that by tagging a release in my own iris repo using this PR branch... I'll add that as a TODO for confirmation to reviewers 👍

If you require further confidence, then currently cf-units has adopted this approach and successfully cycled through its first release (v3.1.0)

@trexfeathers I'm just wondering whether there is any benchmarking related infrastructure that performs version parsing that this PR might upset... I'm thinking that there might be, right?

@trexfeathers I'm just wondering whether there is any benchmarking related infrastructure that performs version parsing that this PR might upset... I'm thinking that there might be, right?

I'm fairly certain that ASV only does tag parsing, and that's obviously all via Git. I can always try running some stuff once I've finished reviewing the changes.

Also of note is that ASV always installs the project (via mpip) into its special environment before running anything, so that should ensure a version is present (I hope?)

Thanks @bjlittle, a few questions/requests for you...

This doesn't align with setuptools_scm recommendations.

Done 👍

How come we no longer have a release variable?

I figure it's just not used anymore. I can't see anywhere in the docs that references it.

Perhaps @tkknight might know this one 🤔

The docs build without any warnings and they render fine, so that's good enough for me

Version displayed in latest docs is now "v0.1.dev72+dirty". Was that expected?

I got 3.3.0 when I tested it. @bjlittle any ideas?

I've done some local benchmarking experiments and there are no signs of trouble there 🙂