Description
For a long time, Setuptools has taken advantage of the --tag-build and --tag-date options of the build via setup.cfg to make builds outside of the release process produce version numbers like 72.1.0.post20240731, so they're not uploaded and are distinct from their released counterparts.
This approach has the unfortunate effect, however, of making setuptools unable to be built from the repo without incorporating that workaround.
For example:
~ 🐚 pip-run -v git+https://github.com/pypa/[email protected] -- -c pass
Collecting git+https://github.com/pypa/[email protected]
Cloning https://github.com/pypa/setuptools (to revision v72.1.0) to /private/var/folders/f2/2plv6q2n7l932m2x004jlw340000gn/T/pip-req-build-b77hkm6t
Running command git clone --filter=blob:none --quiet https://github.com/pypa/setuptools /private/var/folders/f2/2plv6q2n7l932m2x004jlw340000gn/T/pip-req-build-b77hkm6t
Running command git checkout -q 57ec6e527e73f04099836ff2773468a68a5d2fb9
Resolved https://github.com/pypa/setuptools to commit 57ec6e527e73f04099836ff2773468a68a5d2fb9
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: setuptools
Building wheel for setuptools (pyproject.toml) ... done
Created wheel for setuptools: filename=setuptools-72.1.0.post20240731-py3-none-any.whl size=2338151 sha256=464d3ee80c96e970a03c7c1ea21101224cd1692f099176aa9faf05472ff51dc1
Stored in directory: /private/var/folders/f2/2plv6q2n7l932m2x004jlw340000gn/T/pip-ephem-wheel-cache-ljvpiy2m/wheels/87/9b/20/f77304c66ef859fff1279ecc9d4096f80d3c2e0420de454433
Successfully built setuptools
Installing collected packages: setuptools
Successfully installed setuptools-72.1.0.post20240731
So even though the project is built from a tagged release, it produces the post release tag.
Moreover, there are better ways to handle this situation, such as setuptools_scm, which should be viable now that Setuptools has natural dependencies (vendored or not).
I'd like to take a two-stage approach:
- Remove the tags and let Setuptools build whatever version is in the file.
- Adopt setuptools_scm and rely on it to generate the post-release tag.
The first stage gets the project to a state where tagged releases can be built and reflect their number. It also means that untagged commits will be built with that same version, but that seems like a small price to pay.
Maybe these changes can both happen in the same release, but I want to be able to back out stage 2 if it causes undue disruption.