Downstream packages inherit setuptools_scm behavior

Due to this issue: pypa/setuptools-scm#653 and brokenness in setuptools itself it is currently not possible to turn setuptools_scm off if it is installed inside the build environment.

That means if I depend on cmake-build-extension for only the purpose of building CMake extensions and not using the setuptools_scm features I have to set up a bunch of pre-emptive excludes that setuptools_scm is so kind to add for me.

I would suggest that until upstream setuptools and setuptools_scm get their act together that you make setuptools_scm and exta and opt-in via cmake-build-extension[scm] or something similar.

Hi @salotz-sitx, thanks for the investigation on this issue and for reporting! I checked a bit the history, and yes, we do use some logic contained in setuptools_scm for implementing our custom sdist command, and particularly here:

cmake-build-extension/src/cmake_build_extension/sdist_command.py

Line 32 in fea4503

import setuptools_scm.integration

From the one hand, the lucky part is that making it optional would be straightforward since the import is not part of the top-level imports of the module. However, from the other, it would possibly break all the existing packages that use this feature.

I need to double check with extra care about this possible transition and understand what are the overall consequences of this change.

For the records, matplotlib/matplotlib#18971 introduced the setuptools_scm deps into matplotlib, that created the problems discussed in pypa/setuptools-scm#653.

Fair enough. I don't think it would be too disruptive to change this behavior in new versions. Presumably anyone wanting stability at the installation stage should be pinning their dependencies and not aggressively upgrading.