Remove setuptools-scm as build backend?

[Alex Dewar (alexdewar)]

I've marked this as a question because I think we need to work out the details, but it turns out that setuptools-scm doesn't work outside of a git repo, which can be annoying for deployment.

We could just move to something else (uv_build, hatchling), but the advantage of setuptools-scm is that it dynamically generates the package version from git tags, which is convenient. We could not use it for programs, just libraries, or something, but it might be cleaner to just make the switch, even if it means users have to manually update the version number. I think this might be easiest. We could add a CI workflow to check that the git tag version and package version match.

Reported by Ryan (@TinyMarsh).

[Alex Dewar (alexdewar)]

I've made this a discussion because I'm not sure it's obvious what we want to do here... What does everyone think? Happy to go with the majority position!

Ryan (@TinyMarsh) Adrian D'Alessandro (@AdrianDAlessandro) Christopher Cave-Ayland (@cc-a)

[Adrian D'Alessandro (AdrianDAlessandro)]

I think having a dynamic versioning tool is essential for the way we do deployment atm (via GitHub releases). I think the only time this comes up as an issue is when building docker images, which is not the only way we deploy software (although very common). There must be a way to be able to do both?

[Alex Dewar (alexdewar)]

You obvs can just update the version manually before doing a release. I know that's an extra step, but it's not esp onerous. It probs does make sense to have some kind of check that your git tag matches it though.

One option would be to have a choice of build backends, defaulting to something dynamic (either setuptools-scm or uv-dynamic-versioning), but giving the option to use something else in the case that you need it.

What do you think?

The release-please Action seems pretty cool -- it automatically produces releases when you bump the package version in pyproject.toml or wherever -- but it only works if you use conventional commits and I don't think we do that anywhere...

[Adrian D'Alessandro (AdrianDAlessandro)]

Maybe worth a discussion in person? I think there are two distinct users of this template (that might have different needs) we need to consider:

1. Us - How we would prefer to manage releases and version updates. Should we standardise an approach?
2. Others - Should we impose an approach? Should we make it a configurable choice?

There are arguments to use different backends for different types of software. Maybe we should look at providing them as options and also including something in the docs depending on which is chosen?

[Alex Dewar (alexdewar)]

Good ideas. Maybe we should talk about it at the next tech forum?

[Alex Dewar (alexdewar)]

I've just come across this tool, which might be an alternative to setuptools-scm: uv-dynamic-versioning, which is a hatchling plugin.

I'm not sure what the advantages are tbh, but it could be worth a look.