switch versioning to setuptools_scm #11355
Conversation
Helper Script Tests26 tests 26 ✅ 0s ⏱️ Results for commit 4614aad. ♻️ This comment has been updated with latest results. |
5344d9d to
c8cc693
Compare
56ca27f to
16060fe
Compare
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 3m 35s ⏱️ Results for commit 4614aad. ♻️ This comment has been updated with latest results. |
70348f5 to
cfde3e5
Compare
39bbe67 to
120e4b5
Compare
e1078f0 to
9f0936b
Compare
9f0936b to
68b259c
Compare
There was a problem hiding this comment.
This is quite an awesome iteration, @silv-io! We're nearly there! Just found a few nitpicks and leftovers we need to tackle before merging ;) 🚀
6a2bcd7 to
6104e2f
Compare
6104e2f to
27a953b
Compare
There was a problem hiding this comment.
Awesome! Thanks, @silv-io for addressing the comments and questions! I think this is good to get looked at by another set of eyes, get a bit more testing, and then get merged! 🥳 💯
| # setuptools_scm will be installed transparently if not available, Python3 is expected to be present | ||
| if ! python3 -m pip -qqq list | grep -F "setuptools_scm"; then | ||
| python3 -m pip install -qqq setuptools_scm > /dev/null 2>&1 | ||
| fi |
There was a problem hiding this comment.
I understand the reasoning for this, but I would like to discuss if this is something we can somehow avoid? Especially since developers might use make docker-build and use this script, and might not have the venv activated - it might lead to some modifications to the global / pyenv install users did not assume.
Same for the release-helper.sh
There was a problem hiding this comment.
I think we can avoid this specific issue by depending on the venv make target in the docker-build make targets and activating the venv before using the helper.
/cc @alexrashed
There was a problem hiding this comment.
I don't think we should couple the docker-helper or the release-helper to the Makefile, that's even tighter than this coupling with setuptools_scm.
I would propose to keep track of this and tackle this in the coming days (in the next iteration), after some discussion and playing around with possible ways to circumvent this.
Motivation
With #10497 we changed the single-sourcing of the version to prepare for namespace packages.
With #11190 we switched to namespace packages.
We are soon going to start with separating the single namespace package into multiple namespace packages.
In addition, we also want to refactor our release processes such that we do not block the default branch anymore during releases.
This PR moves away from the
VERSIONfiles and introducessetuptools_scmas a preparation for both initiatives:VERSIONfile handling is cumbersome since it has to be done for each package.Changes
version.py,setup.py, andVERSIONfiles and usessetuptools_scminstead.docker-helper.shand therelease-helper.shto work withsetuptools_scm.release-helper.sh.Testing
To test the functionality we can build the docker images and see that they pass our test suite still after the change.
For testing the release process we have the tests here, but also the manual test of the release workflow in the sister PR of a dependent repository.
TODO
release-helper.sh.setuptools_scm) for the helper scripts.make publishin CircleCI on multiple builds of the same commit. Edit: fixed by introducing amake dev-publishwhich stops publishing should the current commit carry a tag.release-helperordocker-helperor implement backwards-compatibility.