Jason R. Coombs

This issue is by design (#2497). Non-conformant versions have been discouraged since ~2014, deprecated in packaging since late 2020 and deprecated in Setuptools since Oct 2021. Projects should adapt to...

Another reason to be cautious about adopting setuptools_scm is because it also implies the scm-based file finder, so adopting it will supersede (or augment) MANIFEST.in, and I'm unaware of a...

Another reason to be cautious about adopting setuptools_scm is because it would need to be declared as a build-time dependency. It would be inappropriate to declare it as a runtime...

> I was thinking that there might be a different approach (more lightweight) for adopting `setuptools-scm` without creating the build-cycle, for example by running `python -m setuptools_scm > some-file` in...

I haven't previously articulated my goals for this effort, so let me do so now: - Setuptools should leverage and illustrate best practices. - Setuptools should not have to implement...

Thank you!

The docs build is failing on main.

On further consideration, maybe this change does deserve a news fragment. Integrators probably have to enact the same workaround to convert the in-dev version to a released version, and that...

I think the solution here is pretty simple: 1. Continue to recommend `pkg_util` as the Python 2 compatible mechanism for namespace package modules. 2. Remove the [setuptools requirement](https://github.com/pypa/setuptools/blob/089cdeb489a0fa94d11b7307b54210ef9aa40511/setuptools/command/build_py.py#L177-L183) that requires...

The downside to the above approach is that we continue to be entrenched in the issues surrounding package discovery (open issue with `find_packages` plus redundancy between defining `packages` and `namespace_packages`).