Dear package maintainer, We want to update python-setuptools to 80.9.0 or newer. However, your package fails to build with it, in our testing Copr: https://copr.fedorainfracloud.org/coprs/churchyard/setuptools-80.9.0/package/python-colcon-core To reproduce, try to build your package in mock with: $ fedpkg --release rawhide mockbuild -N -- --addrepo=https://download.copr.fedorainfracloud.org/results/churchyard/setuptools-80.9.0/fedora-rawhide-x86_64 As the number of failures is rather high, I have not yet tried to look into the details about each individual failure. When you do, please feel free to post relevant part of the logs as comments. Thank you. Let me know if you need help.
python-colcon-core-0:0.20.1-1.fc44.src BuildRequires: python3-setuptools < 80 python3-colcon-core-0:0.20.1-1.fc44.noarch Requires: (python3.14dist(setuptools) < 80~~ with python3.14dist(setuptools) >= 30.3) This impacts at least: python-colcon-alias python-colcon-bazel python-colcon-bundle python-colcon-cmake python-colcon-core python-colcon-installed-package-information python-colcon-meson python-colcon-notification python-colcon-package-information python-colcon-parallel-executor python-colcon-python-setup-py python-colcon-ros python-colcon-ros-bundle python-colcon-ros-domain-id-coordinator
When I allow setuptools 80, I get: test/test_build_python.py FFFFFFFFFFFF ... source_files_before = set(src_base.rglob('*')) rc = event_loop.run_until_complete(python_build_task.build()) > assert not rc E assert not 1 test/test_build_python.py:146: AssertionError ... FAILED test/test_build_python.py::test_build_package[False-False-False-False] FAILED test/test_build_python.py::test_build_package[False-False-False-True] FAILED test/test_build_python.py::test_build_package[False-True-False-False] FAILED test/test_build_python.py::test_build_package[False-True-False-True] FAILED test/test_build_python.py::test_build_package[False-True-True-False] FAILED test/test_build_python.py::test_build_package[False-True-True-True] - ... FAILED test/test_build_python.py::test_build_package[True-False-False-False] FAILED test/test_build_python.py::test_build_package[True-False-False-True] FAILED test/test_build_python.py::test_build_package[True-True-False-False] FAILED test/test_build_python.py::test_build_package[True-True-False-True] - ... FAILED test/test_build_python.py::test_build_package[True-True-True-False] - ... FAILED test/test_build_python.py::test_build_package[True-True-True-True] - a... Also note that this package uses pkg_resources, which is still available in setuptools 80 but will likely be gone in setuptools 81.
I also see https://github.com/colcon/colcon-core/pull/699, which means upstream is aware of this. We will need to make a compact package with setuptools < 81 when they remove setup.py install and pkg_resources anyway, so we could package python-setuptools79 to move forward with this update. Unless you think that colcon can move forward to at least setuptools 80.
> Unless you think that colcon can move forward to at least setuptools 80. For now at least, this is a 'no'. Without getting into the gritty details, the `--symlink-install` option to `colcon build` relies on the `--editable` option to the `develop` verb in setuptools, which disappeared when `easy_install` support was removed in v80. A significant part of the colcon user base leverages symlink installation. We've been making slow progress on moving to a standards-based pipeline in colcon for years now. The editable installation story there has problems as well (namely **completely** ignoring data files), which has thus far blocked progress. > we could package python-setuptools79 to move forward with this update I'm not sure this will actually help us, unless there's a way to implicitly route the sub-projects that colcon is building to use the legacy version when they import from setuptools in their `setup.py`. It might get the tests to pass but the feature would still be broken. I'll really push on getting the remaining blockers for the standards-based pipeline resolved so that colcon can let the target projects dictate the backend and leave setuptools to continue self-destruction on its own time. Hopefully I can land that work before Fedora 44 ships, but this will probably have to regress in rawhide until then.
> unless there's a way to implicitly route the sub-projects that colcon is building to use the legacy version when they import from setuptools in their `setup.py`. colcon-core Requires setuptools < 80, so that's what they would get.
> Hopefully I can land that work before Fedora 44 ships, but this will probably have to regress in rawhide until then. I read that as "go ahead with the setuptools update", is that correct?
This now fails to build and install in rawhide.
> I read that as "go ahead with the setuptools update", is that correct? Affirmative.
The failure to build and install means the robotics lab doesn't build. I guess I'll send a PR to drop this package from it at least until it's fixed.