[BUG] Internal 68.2.0 change breaks all ROS2 python packages

[owend]

setuptools version

68.2.0

Python version

3.10

OS

Ubuntu

Additional environment information

No response

Description

This recent change in setuptools for 68.2.0 described as "Record normalized requirements in dist.metadata object"

a641c78

Probably breaks all downstream python packages built for ros2 using colcon.

colcon/colcon-python-setup-py#56 (comment)

This is going to cause a bunch of cascading failures in other projects. For example:

ArduPilot/ardupilot#24862 (comment)

Stack Overflow is about to get really busy because the tutorials are also broken.

https://robotics.stackexchange.com/questions/104054/building-example-library-of-ros-2

This design flaw in colcon has been "known" since 2021:

colcon/colcon-core#454

But the ROS ecosystem is very large and this will probably take a while to fix.

Unfortunately the root cause is that colcon is feeding output from setup.py into a compiler and expected compilable code but now gets a string representation which is not compilable. The extra <> characters now cause a syntax error.

Expected behavior

Builds using 68.1 do work. Since this is an internal meta-data structure change which seems to be an optimization? I would expect the easiest fix is to revert.

How to Reproduce

Try to build any ROS2 python package built with 68.2
Can add more details in a bit.

Output

 '_normalized_install_requires': {'setuptools': <Requirement('setuptools')>}
                                                ^
SyntaxError: invalid syntax

[abravalheri]

Thank you very much for the feedback @owend.

Have you tried 68.2.1?

[abravalheri]

This design flaw in colcon has been "known" since 2021:

colcon/colcon-core#454

About using the deprecated setup.py CLI: I understand the stance of the project... as long as they understand the consequences of using a deprecated feature, that is OK. (Note that setup.py keeps being a perfectly valid, non-deprecated configuration file; what is deprecated is its "CLI abilities").

However this seems to be unrelated to using setup.py per-se:

Unfortunately the root cause is that colcon is feeding output from setup.py into a compiler and expected compilable code but now gets a string representation which is not compilable. The extra <> characters now cause a syntax error.

Without deep inspection, it seems that serialising arbitrary objects with repr and expecting them to parse as Python would be a very bold decision... I cannot say it is not error prone. I am not sure if colcon is doing exactly that, but at least this is how it sounds by looking at this problem.

[asasine]

@abravalheri I can confirm 68.2.1 mitigates the issue.

[abravalheri]

Thank you very much @asasine for confirming.

@owend, please let me know if that is enough for this issue. If that is OK, we can go ahead and close.

[owend]

Fixed with 68.2.1, thanks!