Operating System:

Ubuntu 24.04.1 LTS 'Noble'

ROS version or commit hash:

Jazzy

RMW implementation (if applicable):

rmw_fastrtps_cpp

RMW Configuration (if applicable):

No response

Client library (if applicable):

colcon

'ros2 doctor --report' output

<COPY OUTPUT HERE>

Steps to reproduce issue

1. Create a workspace directory:

mkdir -p test_ws/src

2. Navigate into the workspace and create and activate a Python virtual environment, including --system-site-packages (required for the build):

cd test_ws/
python3 -m venv .venv --system-site-packages
source .venv/bin/activate

3. Source the ROS 2 Jazzy environment:

source /opt/ros/jazzy/setup.bash

4. Navigate to the source directory and create a pure Python package test_pkg with an executable node test_node:

cd src/
ros2 pkg create --build-type ament_python test_pkg --node-name test_node

5. Install a Python module (for example, pandas) using pip within the virtual environment:

pip3 install -U pandas

6. Modify the test_node.py file to import the pandas module:

import pandas

7. Build the workspace and then source the resulting environment:

colcon build
. install/setup.bash

8. Attempt to run the test_node executable:

ros2 run test_pkg test_node

Expected behavior

The node should run without any import errors related to the pandas module and produce the following output:

Hi from test_pkg.

Actual behavior

The node fails to run and raises a ModuleNotFoundError for the pandas module, as shown in the traceback below:

Traceback (most recent call last):
  File "~/test_ws/install/test_pkg/lib/test_pkg/test_node", line 33, in <module>
    sys.exit(load_entry_point('test-pkg==0.0.0', 'console_scripts', 'test_node')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "~/test_ws/install/test_pkg/lib/test_pkg/test_node", line 25, in importlib_load_entry_point
    return next(matches).load()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/metadata/__init__.py", line 205, in load
    module = import_module(match.group('module'))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/importlib/__init__.py", line 90, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1387, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 995, in exec_module
  File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
  File "~/test_ws/install/test_pkg/lib/python3.12/site-packages/test_pkg/test_node.py", line 1, in <module>
    import pandas as pd
ModuleNotFoundError: No module named 'pandas'
[ros2run]: Process exited with failure 1

Additional information

On recent Ubuntu systems (24.04+), there's a shift away from installing Python packages globally, pushing users towards virtual environments for better project isolation. While ament_cmake packages correctly use the Python interpreter specified in the virtual environment (via the #!/usr/bin/env python3 shebang), ament_python packages might be mishandling this.

The problem arises during the colcon build process. Instead of embedding a shebang that points to the Python interpreter within the activated virtual environment, the build tools for ament_python seem to be hardcoding the system's default Python interpreter in the generated executable scripts.

Because of this, when we try to run a Python node from an ament_python package after installing a library like pandas only in the virtual environment, the system's Python is invoked. This system-level Python doesn't know about the packages installed in your isolated virtual environment, leading to the ModuleNotFoundError.

The reason this might not have been noticed earlier is likely because developers (including myself) may have had these Python libraries installed globally on their systems. In that scenario, regardless of which Python interpreter the script tried to use, the pandas library would have been accessible, masking the underlying shebang issue. Now that Ubuntu is more strictly recommending virtual environments, this discrepancy between ament_cmake and ament_python package handling is becoming apparent.