0
$\begingroup$

Context

I’m running ROS 2 Jazzy on Ubuntu 24.04, and I need to use some Python 3.12 external libraries.

What I tried

In this GitHub issue they talked about this problem. From my understanding ROS2 is not meant to be used with virtual envs.
As suggested here, i tried the following

# 1) Create and activate venv
python3.12 -m venv ~/my_venv
source ~/myvenv/bin/activate

# 2) Install external packages
pip install foo bar

# 3) Source ros2 env
source /opt/ros/jazzy/setup.bash

# 4) Build with colcon
colcon build

Despite activating the virtual environment, colcon still invokes /usr/bin/python3 and it searches packages inside /opt/ros/jazzy/lib/python3.12/site-packages, while ignoring packages installed in ~/my_venv.
Looks like it's because colcon has been installed with apt, so it will always use the default interpreter.

What I would do

Since it's not defined a "best practice" to handle external python packages with ROS2, I'd highlight the solutions suggested by amjad-haider (also stated here):

python3 -m venv ~/my_venv
export PYTHONPATH="~/my_venv/lib/python3.12/site-packages:$PYTHONPATH"
source ~/my_venv/bin/activate
colcon build

tl;dr It adds the site-packages path from your virtual environment to the PYTHONPATH variable, so that colcon also searches there to find your custom packages.

Question

Could this be considered the best practice for handling external Python packages with ROS 2? Are there any potential issues I'm overlooking?

$\endgroup$

1 Answer 1

0
$\begingroup$

This is definitely not best practice. You will run into problems because you are mixing python versions by using the binaries with your different python implementation.

The installed python content in /opt/ros is fixed to your system version of Python.

If you want to use a custom python version in a virtual environment you need to build everything that has python content from source while making sure that your custom virtual environment is always active any time you interact with the workspace.

Because much of the tools are python based, you'll effectively want to just follow the standard build from source instructions:

https://docs.ros.org/en/jazzy/Installation/Alternatives/Ubuntu-Development-Setup.html

But to reemphasize make sure that any interaction with the workspace is using you virtual environment building or runtime. If you mix the python versions at any point there's no way to audit or easily reverse the intermingling and you will want to clear all build artifacts and start over.

$\endgroup$
5
  • $\begingroup$ I agree with you about the "mixed python version" problem, but what if I wanted to use a venv with the exact same python version of my system? E.g. my system has python3.12 installed (default for ubuntu noble) and I'd use a python3.12 venv with my external packages installed. In this way I'd get rid of the "externally managed environment" error when trying to install those packages... $\endgroup$ Commented Apr 20 at 9:54
  • $\begingroup$ That will still likely end up with weird behaviors unless you find a way to keep the available modules 100% in sync. It there's any modules with different versions and it missing in the two parallel environments you get errors and or crashes. $\endgroup$ Commented Apr 20 at 16:14
  • $\begingroup$ Based on your follow-up it sounds like this is an XY problem. en.wikipedia.org/wiki/XY_problem with missing context about your underlying problem and asking questions about an assumed solution approach. You are more likely to get things working better if you take a step back and explain what your goals are. $\endgroup$ Commented Apr 20 at 16:18
  • $\begingroup$ I have some code written using ROS2 Humble, running on Ubuntu 22.04 with Python3.10. What I have to do is to make it run using ROS2 Jazzy on Ubuntu 24.04, with Python3.12. The original code uses lots of external python packages, which don't come with ROS2. On the original system, they just did "pip install ..." for all packages. With python 3.12 this is not possible, so I have to understand what's the best way to handle those external packages. Force-installing them system-wide doesn't seem to be a good solution... That's why I thought this could have been a good option $\endgroup$ Commented Apr 20 at 18:56
  • $\begingroup$ It's no longer a recommended practice to install onto the system. But it's still possible. That's still how rosdep continues to works. But this is a completely different question now. Please ask it as a new question. $\endgroup$ Commented Apr 21 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.