Redo move to pyproject.toml

[suvayu]

This reverts commit 528a0c84ca58ea42f14997d74255950817dbcae4.

Attempt 2:

• move to pyproject.toml and
• use setuptools_scm & git tags for version management

Re spine-tools/Spine-Toolbox#1934

Checklist before merging

• [ ] ~Documentation (also in Toolbox repo) is up-to-date~
• [ ] ~Release notes in Toolbox repo have been updated~
• [ ] ~Unit tests have been added/updated accordingly~
• [ ] ~Code has been formatted by black~
• [x] Unit tests pass

[suvayu]

I enabled and tested the CI in my fork, they all passed. But it's a bit difficult since it pulls in from the main repo in the requirements file/workflow. But otherwise I think it's a good idea.

Maybe we can also do a throwaway commit in the test branch, that updates the requirements file to point to other test branches? But that might be too much work.

As far as I see it, the only issue is the automatic versioning. Which is a problem only with spine-items because of how it depends back on spinetoolbox. So maybe inspecting that closely is sufficient.

[PekkaSavolainen]

Hi @suvayu, I'm wondering why setuptools-scm autogenerates a version.py where the version str is '0.13.0.dev523+g61c35c0'. What does this mean and why is the first part 0.13 when it probably should be 0.31 since spinedb-api in master is now in version 0.30.0.dev0?

[suvayu]

Hi @PekkaSavolainen , I think your local repo doesn't have the latest tags. If you do git fetch --tags, that should resolve it.

Essentially setuptools_scm looks at all the Git tags that look like version numbers, sorts them as version numbers (so 0.30.0 would come after 0.3.0), and picks the latest. Then it creates the package version based on the distance of HEAD from that tag. The general formula is: <next-version>.dev<distance from HEAD>+g<current commit> (the part after dev is actually quite similar to git describe --tags).

So the current master should generate something like 0.30.0.dev22+gbd337e8, meaning the next version should be 0.30.0, and currently it is 22 commits ahead of 0.29.0 at commit bd337e8. If we want, we can of course override it to do a patch release like 0.29.1 (that option is part of the release command in the spine-conductor repo). If you were to do this with a tagged commit, the version number would simply be the tag (since distance to HEAD would be 0 in that case).

If you want to understand the logic by experimenting a bit, you can do something like this:

In [1]: from setuptools_scm import get_version
In [2]: get_version("/path/to/repo", version_scheme="release-branch-semver")
Out[2]: '0.30.0.dev22+gbd337e8'

If you change the path to different repositories, and repeat the above, it should become clear.

[PekkaSavolainen]

... I think your local repo doesn't have the latest tags. If you do git fetch --tags, that should resolve it.

...

Thanks for the explanation. The problem was with my local tags and it makes more sense now.

[PekkaSavolainen]

The autogenerated version.py should be added to .gitignore in all repos.

EDIT version.py in spinedb_api, spine-items, and spine-engine repos _version.py in spinetoolbox repo

[suvayu]

Done, for all repos