SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.

[ijnek]

SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools. shows up when building any python package in Ubuntu22.04 with ROS2 Rolling.

Reproduce Instructions (On Ubuntu22.04):

# Clone ros2 examples into workspace/src
git clone [email protected]:ros2/examples.git

# In workspace, build the package
colcon build --packages-select examples_rclpy_minimal_publisher

Output:

Starting >>> examples_rclpy_minimal_publisher
--- stderr: examples_rclpy_minimal_publisher                   
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
---
Finished <<< examples_rclpy_minimal_publisher [0.73s]

Summary: 1 package finished [0.91s]
  1 package had stderr output: examples_rclpy_minimal_publisher

---

Perhaps this is coming from the direct invocations of setup.py in ament_python_install_package.cmake?

I swear this was being discussed somewhere before, but I can't seem to find the conversation.

Related: https://answers.ros.org/question/396439/setuptoolsdeprecationwarning-setuppy-install-is-deprecated-use-build-and-pip-and-other-standards-based-tools/?answer=398274#post-id-398274

[clalancette]

Perhaps this is coming from the direct invocations of setup.py in ament_python_install_package.cmake?

Yes, that is probably the case. This needs to be investigated, but I suspect it will take changes to colcon, ament, and every single python package in the ROS 2 ecosystem. This is on the list to investigate, but since the Humble feature freeze is in 3 working days, this is almost certainly an item for the next release.

[ijnek]

Could you confirm that when you say an item for the next release, you mean this will be addressed as a bug fix into Humble in a future synchronization, and not for the next ROS2 distro?

[clalancette]

Could you confirm that when you say an item for the next release, you mean this will be addressed as a bug fix into Humble in a future synchronization, and not for the next ROS2 distro?

It's hard to say, it depends on the nature of the fix. If the fix doesn't break any ABI or API (I guess since this is Python, we'd be worried about API), then we can consider backporting it to Humble once we know what needs to be done.

[ijnek]

Got it. I'd expect we'd want at least a supression of the warning for Humble though as it otherwise shows up everywhere.

[clalancette]

Got it. I'd expect we'd want at least a supression of the warning for Humble though as it otherwise shows up everywhere.

If you have an idea on how to suppress it, a PR for that would be most welcome.

[robberthofmanfm]

Just FYI, I'm on Ubuntu 20.04, Python 3.8.10, ROS2 Foxy and when I do
ros2 pkg create --build-type ament_python newpackage
colcon build
I get these warnings too:
/home/user/.local/lib/python3.8/site-packages/setuptools/dist.py:739: UserWarning: Usage of dash-separated 'script-dir' will not be supported in future versions. Please use the underscore name 'script_dir' instead

[clalancette]

/home/user/.local/lib/python3.8/site-packages/setuptools/dist.py:739: UserWarning: Usage of dash-separated 'script-dir' will not be supported in future versions. Please use the underscore name 'script_dir' instead

Note that this is a different warning, though it is also caused by using a newer version of setuptools. In any case, all of those particular warnings have been fixed in later ROS 2 distributions.

[robberthofmanfm]

Oh yes, indeed, I copied the wrong warning message. I'm also getting
/home/user/.local/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.

Thanks for the fix, I'll be upgrading as soon as it's released

[ijnek]

I guess this issue isn't specific to Ubuntu22.04 nor ROS2 Rolling, but rather to the setuptools version installed.

@robberthofmanfm what do you get with the following command:

pip show setuptools | grep Version
# I get 'Version: 59.6.0'

If the version is above v58.3.0, I'd expect the warning to show up.

[robberthofmanfm]

Version: 60.10.0

[dwffls]

I'd like to add that when building with the --symlink-install option I get the following error:

usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --install-layout not recognized

Seems to also be coming from the changes which were made to setuptools.
However opposite to the other errors in this thread, the build completely fails instead of giving only warnings.

[ijnek]

I'd like to add that when building with the --symlink-install option I get the following error:

usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --install-layout not recognized

Seems to also be coming from the changes which were made to setuptools.
However opposite to the other errors in this thread, the build completely fails instead of giving only warnings.

@dwffls
I started getting this exact error yesterday too and haven't figured out the cause. I think its better to post a new, separate issue if one doesnt exist yet.

[clalancette]

I started getting this exact error yesterday too and haven't figured out the cause. I think its better to post a new, separate issue if one doesnt exist yet.

Agreed. Probably to https://github.com/colcon/colcon-core .

[nuclearsandwich]

This isn't on my immediate queue but I'm putting the assign on myself to keep track of this over the next long while. We're generally expecting setuptools to match the version in Jammy and the process of moving build backends won't be a small one.

[wilcobonestroo]

Today, I also tried to create a basic Python package in ROS 2 Humble and I get more deprication warnings.

After entering

$ ros2 pkg create --build-type ament_python lalala
$ colcon build --symlink-install --packages-select lalala

I get the output:

Starting >>> lalala
--- stderr: lalala
/usr/lib/python3/dist-packages/setuptools/command/easy_install.py:158: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 0.1.43ubuntu1 is an invalid version and will not be supported in a future release
  warnings.warn(
/usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: PkgResourcesDeprecationWarning: 1.1build1 is an invalid version and will not be supported in a future release
  warnings.warn(
---
Finished <<< lalala [0.88s]

Summary: 1 package finished [1.04s]
  1 package had stderr output: lalala

[brean]

I notice the same problem (ros2 humble as well), following the official documentation on creating a ROS2 package using ros2 tools to create a simple project and trying to build it: ros2 pkg create... and colcon build, similar to how @wilcobonestroo did it. best workaround for now seems to just downgrade setuptools.

As already noticed in the initial comment for this issue by @ijnek the problem lies in calling python directly in ament_python_install_package.cmake line 143 / ament_python_install_package.cmake line 164 which is not following PEP-518 so its behavior will not be changed back in the future (discussion about it for example in pypa/setuptools#2088 and pypa/setuptools#510), so this is not a bug.

How could this issue be resolved for ament_cmake and the documentation?

1. Still use setuptools but with pip instead of calling python directly (maybe switch to setup.cfg files while we are at it?).
2. Switch to flit as default build system and ditch setuptools.
3. Find another way to stay compliant with PEP-517 and PEP-518 (another build system)?

[brean]

@mengchaoheng you have another issue that is not connected to the SetuptoolsDeprecationWarning that is already closed here: ros2/examples#351 .

[lonebots]

I am having the SetupToolDeprecationWarning when I was trying to build the package as per this ros2 tutorial. I have Ubuntu 22.04 running ROS2 Humble on my machine. Is there a fix available for this issue?

[brean]

EDIT: ignore this, see last comment by @clalancette

@lonebots as I mentioned:

best workaround for now seems to just downgrade setuptools.

[carmiac]

I'm still having this issue in an updated version of Ubuntu 22.04/ROS2 Humble. The downgrade works, but I'd rather not have to do that on every machine we have.

[clalancette]

The recommended workaround here is not to downgrade setuptools; that leaves you with a system that is not tested.

Instead, the recommended workaround is to suppress that particular warning. See https://robotics.stackexchange.com/a/24349 for details.

[slim71]

Is there any update on this now that Iron has been released?

[clalancette]

Yes, we have a fix in progress: https://discourse.ros.org/t/call-for-testing-standards-based-python-packaging-with-colcon/32008

[TunVunDerBunn]

was this already fixed? I still get the warning, using the official docker container?

[clalancette]

was this already fixed? I still get the warning, using the official docker container?

Still the same answer as #382 (comment) , unfortunately. We hope to have it fixed for Jazzy in May 2024.

[Ryanf55]

Hello!

I've come across some concerning behavior when you install python3.12-dev on Ubuntu 22.04. It breaks ament_cmake_python due to the removal of distutils! I was hoping to work with a friend who uses MacOS and we had some python3.12 specific issues, so naturally, I just added it to my system.

ryan@B650-970:~/Dev/ros2_ws/src/ardupilot$ sudo apt install python3.12-dev
...

But now, if you try to colcon build, it blows up.

ryan@B650-970:~/Dev/ros2_ws/src/ardupilot$ colcon build
...
Traceback (most recent call last):
  File "/home/ryan/Dev/ros2_ws/src/ardupilot/build/ardupilot_msgs/ament_cmake_python/ardupilot_msgs/setup.py", line 1, in <module>
    from setuptools import find_packages
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 10, in <module>
    import distutils.core
ModuleNotFoundError: No module named 'distutils'
gmake[2]: *** [CMakeFiles/ament_cmake_python_build_ardupilot_msgs_egg.dir/build.make:70: CMakeFiles/ament_cmake_python_build_ardupilot_msgs_egg] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:447: CMakeFiles/ament_cmake_python_build_ardupilot_msgs_egg.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
gmake: *** [Makefile:146: all] Error 2
---
Failed   <<< ardupilot_msgs [1.93s, exited with code 2]

Summary: 0 packages finished [2.51s]
  1 package failed: ardupilot_msgs
  1 package had stderr output: ardupilot_msgs
  2 packages not processed

This is super odd, because my system python3 still refers to the 3.10.12 version that is default with Ubuntu 22, not the optional 3.12 I just added.

ryan@B650-970:~/Dev/ros2_ws/src/ardupilot$ which python3
/usr/bin/python3
ryan@B650-970:~/Dev/ros2_ws/src/ardupilot$ python3 --version
Python 3.10.12

Perhaps there is a way using apt to indicate that you can't have ros-humble-ament-cmake-python/jammy,now 1.3.7-1jammy.20240125.200351 and python3.12-dev at the same time, much like you can't have gazebo classic and gazebo harmonic binaries at the same time.

[cottsay]

@Ryanf55, the problem you're facing has nothing to do with the deprecation of setup.py.

The CMake logic currently part of ROS 2 will select the most recent Python interpreter installed on your system when it needs to invoke a Python subprocess. This is not necessarily the interpreter behind by the python3 executable, and it is not necessarily the chosen "default" interpreter for your operating system for which python dependencies are installed.

Distutils has indeed been removed from the Python standard library, which is why setuptools prior to 66.1.0 will not work on Python 3.12. If you had a newer version of setuptools you would not experience this error, but it's likely that you'd hit other problems later in the build due to unavailable Python dependencies which are packaged for Python 3.10 and not Python 3.12.

To work around this issue, pass this to your builds: --cmake-args -DPython3_EXECUTABLE=/usr/bin/python3 --no-warn-unused-cli
Alternatively, if it is possible to remove the newer Python interpreters from your system so that the one selected is the system default, that would work too.

The ROS 2 team discussed this issue last week, but we haven't arrived at a proposed solution quite yet.

[Ryanf55]

Thanks for the detailed information and workaround. I'm going to move this to a separate issue because it's an error instead of a warning and caused by different mechanisms. See just above ^

[varunagrawal]

@clalancette thanks for the various updates and progress on this issue. I haven't yet seen the Infrastructure Community meeting recording due to a lack of time, however I wanted to verify with you whether an easy fix is to just replace python setup.py install with pip install . instead? This has the benefits of zero changes to setup.py, no need to upgrade to a pyproject.toml, API/ABI compatibility, and also makes for an easy fix.

Maybe this was already addressed in the Infrastructure Community meeting, so I apologize for bringing it up, but getting an update from you or anyone else in the Infrastructure Community would be amazing.

Thanks again for the great work with ROS2!

[felixf4xu]

However opposite to the other errors in this thread, the build completely fails instead of giving only warnings.

I would like to highlight this: when used with --symlink-install, this is an error, and the installation is skipped.

I'm fine with the warning message, but it's not acceptable to the installation failure hidden by a warning message.

[ClaudioCimarelli]

was this already fixed? I still get the warning, using the official docker container?

Still the same answer as #382 (comment) , unfortunately. We hope to have it fixed for Jazzy in May 2024.

How is the progress with this? I am facing this issue with Jazzy.