Pin setuptools_scm to <8

[pganssle]

There are some breaking changes, and this is making it so that the _version.py file generated is not compatible with Python 2 anymore. I don't see an obvious or easy way to figure out what version of setuptools_scm is in use, so we'll just pin the version for now.

I recommend removing setuptools_scm entirely in the future.

Closes #1344

[tucked]

Yup, type annotation in the version template were added in 8.0: https://github.com/pypa/setuptools_scm/blob/fee09f4cb57de4a50becc4eba0639bbb68d86725/CHANGELOG.md#v800

[alerque]

This actually breaks building the Arch Linux package, which was fine before. The issue there is we have python-3.11.7 which is fine, but also python-setuptools-scm-8.0.4, which is now arbitrarily blocked. I am not a Python ninja but I'm pretty sure there is a way to specify dependencies (including pinning) that are only relevant for specific versions of Python. I think that is needed in this case as you only want to force using an old setuptools if the Python version is old. For rolling-release environments like Arch Linux you definitely don't want to block using the current stable releases of things!

[pganssle]

This actually breaks building the Arch Linux package, which was fine before. The issue there is we have python-3.11.7 which is fine, but also python-setuptools-scm-8.0.4, which is now arbitrarily blocked. I am not a Python ninja but I'm pretty sure there is a way to specify dependencies (including pinning) that are only relevant for specific versions of Python. I think that is needed in this case as you only want to force using an old setuptools if the Python version is old. For rolling-release environments like Arch Linux you definitely don't want to block using the current stable releases of things!

I don't see why Arch Linux is respecting those pins at all. Package managers usually handle the build dependencies themselves, and if you're in a rolling release distro, how would it even make sense to pin this?

[alerque]

I don't see why Arch Linux is respecting those pins at all. Package managers usually handle the build dependencies themselves, and if you're in a rolling release distro, how would it even make sense to pin this?

We do manually provide the dependencies but using a PEP517 build system typically means it checks that what has been provided by the system packages meets the criteria. Pins like this that are not technically correct (much more aggressive than they actually need to be) mean we have to patch them out to build.

[pganssle]

This actually is correct, it is not more aggressive than it needs to be, since setuptools_scm made breaking changes in 8.0 that we do not want, regardless of the version of Python used to do the build.

If you build from the release sdists you shouldn't need setuptools_scm at all, if that helps.

[nanonyme]

Have you considered finally dropping Python 2 support? We're starting to reach the point where adding this kind of pinning breaks things for more people than simply dropping Python 2 support.

[tucked]

setuptools_scm made breaking changes in 8.0 that we do not want,

Ya, that makes sense...
Py2 support is claimed regardless of the Python version used to build.
Py2 support can't be claimed if type annotations are used.

Type annotations are more valuable than py2 support, though. We should drop py2 support.

[pganssle]

Please stop suggesting that we drop Python 2 support. It isn't like it's something I haven't noticed would make the maintenance of this project easier. Even a cursory search of the open or closed issues would find the relevant information.

[pganssle]

And to be honest, the amount of bitrot I've experienced just trying to do literally the same thing that used to work (run tests) has made me way less enthusiastic about contributing to this by adopting the kinds of aggressive support policies that are the natural conclusion of dropping support for a package when it becomes mildly inconvenient.

[nanonyme]

Please don't get worked up. It was just trying to be a helpful suggestion to reduce your work. Currently oldest Python that Python projects are expected to be able to support without having to fork dependencies is 3.8.

[bnavigator]

If you build from the release sdists you shouldn't need setuptools_scm at all, if that helps.

That's not entirely correct. If you build a wheel from the sdist without setuptools_scm, you get the wrong version number:

[    3s] + /usr/bin/python3.9 -mpip wheel --verbose --progress-bar off --disable-pip-version-check --use-pep517 --no-build-isolation --no-deps --wheel-dir ./build .
[    4s] Processing /home/abuild/rpmbuild/BUILD/python-dateutil-2.9.0.post0
[    4s]   Preparing metadata (pyproject.toml): started
[    4s]   Running command Preparing metadata (pyproject.toml)
[    4s]   <string>:18: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead.
[    4s]   /usr/lib/python3.9/site-packages/setuptools/_distutils/dist.py:265: UserWarning: Unknown distribution option: 'use_scm_version'
[    4s]     warnings.warn(msg)
[    4s]   running dist_info
[    4s]   creating /tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info
[    4s]   writing /tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/PKG-INFO
[    4s]   writing dependency_links to /tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/dependency_links.txt
[    4s]   writing requirements to /tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/requires.txt
[    4s]   writing top-level names to /tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/top_level.txt
[    4s]   writing manifest file '/tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/SOURCES.txt'
[    4s]   reading manifest file '/tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/SOURCES.txt'
[    4s]   reading manifest template 'MANIFEST.in'
[    4s]   warning: no previously-included files matching '__pycache__' found anywhere in distribution
[    4s]   warning: no previously-included files matching '*.py[co]' found anywhere in distribution
[    4s]   adding license file 'LICENSE'
[    4s]   writing manifest file '/tmp/pip-modern-metadata-dtxxy89m/python_dateutil.egg-info/SOURCES.txt'
[    4s]   creating '/tmp/pip-modern-metadata-dtxxy89m/python_dateutil-0.0.0.dist-info'
...
[    4s]   adding 'python_dateutil-0.0.0.dist-info/LICENSE'
[    4s]   adding 'python_dateutil-0.0.0.dist-info/METADATA'
[    4s]   adding 'python_dateutil-0.0.0.dist-info/WHEEL'
[    4s]   adding 'python_dateutil-0.0.0.dist-info/top_level.txt'
[    4s]   adding 'python_dateutil-0.0.0.dist-info/zip-safe'
[    4s]   adding 'python_dateutil-0.0.0.dist-info/RECORD'
[    4s]   removing build/bdist.linux-x86_64/wheel
[    4s]   Building wheel for python-dateutil (pyproject.toml): finished with status 'done'
[    4s]   Created wheel for python-dateutil: filename=python_dateutil-0.0.0-py2.py3-none-any.whl size=229807 sha256=eddf55d0134fb65552110d09d40bdf106a3a1c0b6264921bf4e52461f8e8d37c
[    4s]   Stored in directory: /home/abuild/.cache/pip/wheels/09/c6/3a/7f9fb997dcec5f15b190ef05e0a3d1f3b039f857a056699f70
[    4s] Successfully built python-dateutil

Luckily, if you don't want to build for python2, you can ignore the pinning and use setuptools_scm 8 just fine.

Also, if you need to create a backwards-compatible _version.py you can use version_file_template.

[nanonyme]

It might be possible to use Python version identifiers in pyproject.toml for a better workaround

[bnavigator]

It might be possible to use Python version identifiers in pyproject.toml for a better workaround

Not really, because you create a pure py2.py3-none-any.whl which gets uploaded to PyPI and must work for all advertised pythons.