Downstream packages inherit setuptools_scm behavior

[salotz-sitx]

Due to this issue: https://github.com/pypa/setuptools_scm/issues/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.

[diegoferigo]

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:

https://github.com/diegoferigo/cmake-build-extension/blob/fea4503c3a77ca1169dd84f1c09b39b3b8760555/src/cmake_build_extension/sdist_command.py#L32

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, https://github.com/matplotlib/matplotlib/pull/18971 introduced the setuptools_scm deps into matplotlib, that created the problems discussed in https://github.com/pypa/setuptools_scm/issues/653.

[salotz-sitx]

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.