[EzraBrooks]

ament_cmake packages install their own Python modules through ament_cmake_python, which they declare as a buildtool_depend. Those were not scanned, so e.g. rosidl_cmake, ament_cmake_test, angles, srdfdom and rosbag2_storage_mcap were built once, with their modules in the site-packages of the build-time Python only.

Scan buildtool_depend/buildtool_export_depend for the known markers (not for any "python" name: a plain python3 build tool stays ignored), and add rosidl_pycommon to the markers (rosidl_generator_rs, ros_gz_bridge).

[traversaro]

Thanks!

[traversaro]

One agent noted this:

1. Low priority: inactive build-tool dependencies still trigger Python variants.

The new comprehension in recipes.py, lines 175–183 reads every dependency name without checking dependency.evaluated_condition.

For example:
<buildtool_depend condition="$ROS_VERSION == 1">
ament_cmake_python
</buildtool_depend>

With ROS_VERSION=2, I verified that the dependency evaluates to false, but _package_needs_python() returns true. Consequently, an otherwise C++ package receives Python host/run requirements and unnecessary Python variants.

The existing checks for ordinary dependencies already behave this way, so the PR follows the current conservative approach. I would treat this as a follow-up, not a merge blocker. If detection should respect the selected environment, reuse _evaluated_dependency_names() and address both scans consistently.

This is totally true, but not introduced in this PR.