`build --wheel` breaks with `setuptools` > `60.10.0` (`61.0.0`)

I have a project, which uses build to build a wheel. It has the following pyproject.toml file:

[build-system]

build-backend = "setuptools.build_meta"

requires = [
    "jupyter_packaging==0.10.3",
    "jupyterlab==3.1.13",
    "setuptools==60.10.0"
]

As soon as I set setuptools==61.0.0, which is the next version on PyPI (https://pypi.org/project/setuptools/#history) the build command fails with the following error:

$ python3 -m build --wheel
Traceback (most recent call last):
  File "/home/jovyan/.virtualenvs/training_env/lib/python3.8/site-packages/pep517/in_process/_in_process.py", line 363, in <module>
    main()
  File "/home/jovyan/.virtualenvs/training_env/lib/python3.8/site-packages/pep517/in_process/_in_process.py", line 345, in main
    json_out['return_val'] = hook(**hook_input['kwargs'])
  File "/home/jovyan/.virtualenvs/training_env/lib/python3.8/site-packages/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
    return hook(config_settings)
  File "/tmp/build-env-zuy9gtml/lib/python3.8/site-packages/setuptools/build_meta.py", line 177, in get_requires_for_build_wheel
    return self._get_build_requires(
  File "/tmp/build-env-zuy9gtml/lib/python3.8/site-packages/setuptools/build_meta.py", line 159, in _get_build_requires
    self.run_setup()
  File "/tmp/build-env-zuy9gtml/lib/python3.8/site-packages/setuptools/build_meta.py", line 174, in run_setup
    exec(compile(code, __file__, 'exec'), locals())
  File "setup.py", line 7, in <module>
    from jupyter_packaging import (
  File "/tmp/build-env-zuy9gtml/lib/python3.8/site-packages/jupyter_packaging/__init__.py", line 6, in <module>
    from .setupbase import *
  File "/tmp/build-env-zuy9gtml/lib/python3.8/site-packages/jupyter_packaging/setupbase.py", line 37, in <module>
    from setuptools.config import StaticModule
ImportError: cannot import name 'StaticModule' from 'setuptools.config' (/tmp/build-env-zuy9gtml/lib/python3.8/site-packages/setuptools/config/__init__.py)
/home/jovyan/.virtualenvs/training_env/lib/python3.8/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (jupyter_packaging==0.10.3, jupyterlab==3.1.13, setuptools==61.0.0)
* Getting dependencies for wheel...

ERROR Backend subproccess exited when trying to invoke get_requires_for_build_wheel

The changelog mentions, that a few classes have been deprecated (though not deleted): https://setuptools.pypa.io/en/latest/history.html#v61-0-0

Do I need to provide any more detail about the project, or is this sufficient? I might be able to give more info, depending on what kind of details are needed.

[ZelphirKaltstahl]

Actually with version setuptools==60.10.0 the build does work, but not with setuptools==61.0.0. However, if they are not using semantic versioning, then that could be a “minor” release. It would seem to be one more reason to set an upper limit for setuptools because apparently it could break ones flow at any time, if not limited upwards. I just don’t like things working at one point in time and then the same thing not working later, because of a dependency that broke things. If things break, I want that to be because of things I change, not others,whose actions I have no control over. I don’t think it is possible to achieve this without setting version limits of versions, where I know stuff to be working.

I will give that article a read though, and see, if there is any reasoning, that I do not et know about and that changes my mind : )

[layday]

If jupyter_packaging does not declare properly, which version of setuptools is it relies on, that explains things.

jupyter_packaging could not have known in advance that a new setuptools release would have broken compatibility, and pinning at less than the next major version of setuptools (as is often done in other ecosystems) would be overly restrictive because setuptools does not use semantic versioning (this change was in fact introduced in a minor release), and would come with a plethora of pitfalls.