ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

The output of the first command is /home/me/catkin_ws/src/my_package/venv/bin/python and of the second is Python 2.7.15+. I am inside a virtual environment, as you can see.

This is most likely the cause of you not being able to import the packages listed in the package manifest: rosdep will use your OS' package manager -- which in the case of Ubuntu (and Debian) would be apt -- to install the system dependencies that you've listed in your package's manifest.

For python-pandas for instance, it would lookup the rosdep rule for that key (here) and resolve it to python-pandas (in this case the rosdep key resolves to the same Ubuntu/Debian package name, but that is a coincidence).

It would then ask apt to install the python-pandas Debian package. On Ubuntu (and Debian), that would result in the Python 2 version of that package getting installed in the default system location: /usr/lib/python2.7/dist-packages/pandas.

apt does not take any virtual environments into account, it will just install in the system default location (or really: it installs files in whichever location is specified in the .deb package).

This immediately means that the packages are installed, so rosdep will be happy (as apt reports it has installed whatever rosdep asked of it), but the packages will not be available in your virtual environment.

However, whenever I try to do pip list [..] I don't see them in the list.

this should be clear now: pip will look in your virtual environment, and as the packages have not been installed there, it will not list them as available.

The output of the first command is /home/me/catkin_ws/src/my_package/venv/bin/python and of the second is Python 2.7.15+. I am inside a virtual environment, as you can see.

This is most likely the cause of you not being able to import the packages listed in the package manifest: rosdep will use your OS' package manager -- which in the case of Ubuntu (and Debian) would be apt -- to install the system dependencies that you've listed in your package's manifest.

For python-pandas for instance, it would lookup the rosdep rule for that key (here) and resolve it to python-pandas (in this case the rosdep key resolves to the same Ubuntu/Debian package name, but that is a coincidence).

It would then ask apt to install the python-pandas Debian package. On Ubuntu (and Debian), that would result in the Python 2 version of that package getting installed in the default system location: /usr/lib/python2.7/dist-packages/pandas.. There is also a Python 3 version of the pandas rosdep key (here), but that wouldn't change what happens (it would just install the Python 3 version of Pandas in the system default location).

apt does not take any virtual environments into account, it will just install in the system default location (or really: it installs files in whichever location is specified in the .deb package).

This immediately means that the packages are installed, so rosdep will be happy (as apt reports it has installed whatever rosdep asked of it), but the packages will not be available in your virtual environment.

However, whenever I try to do pip list [..] I don't see them in the list.

this should be clear now: pip will look in your virtual environment, and as the packages have not been installed there, it will not list them as available.

The output of the first command is /home/me/catkin_ws/src/my_package/venv/bin/python and of the second is Python 2.7.15+. I am inside a virtual environment, as you can see.

This is most likely the cause of you not being able to import the packages listed in the package manifest: rosdep will use your OS' package manager -- which in the case of Ubuntu (and Debian) would be apt -- to install the system dependencies that you've listed in your package's manifest.

For python-pandas for instance, it would lookup the rosdep rule for that key (here) and resolve it to python-pandas (in this case the rosdep key resolves to the same Ubuntu/Debian package name, but that is a coincidence).

It would then ask apt to install the python-pandas Debian package. On Ubuntu (and Debian), that would result in the Python 2 version of that package getting installed in the default system location: /usr/lib/python2.7/dist-packages/pandas. There is also a Python 3 version of the pandas rosdep key (here), but that wouldn't change what happens (it would just install the Python 3 version of Pandas in the system default location).

apt does not take any virtual environments into account, it will just install in the system default location (or really: it installs files in whichever location is specified in the .deb package).

This immediately means that the packages are installed, so rosdep will be happy (as apt reports it has installed whatever rosdep asked of it), but the packages will not be available in your virtual environment.

However, whenever I try to do pip list [..] I don't see them in the list.

this should be clear now: pip will look in your virtual environment, and as the packages have not been installed there, it will not list them as available.


Edit:

is there a way of installing the dependencies in the virtual environment with a ROS tool or I need to e.g. install the dependencies manually (from e.g. a requirements.txt file)?

rosdep will only use apt on Ubuntu/Debian and pip for certain dependencies (typically recognisable by the -pip suffix on their rosdep key). As Python virtualen environments don't wrap/redirect apt, nor where apt installs Python modules, I would classify this as a shortcoming of how Python virtual environments work (combined with how rosdep prefers apt on Ubuntu/Debian and how Ubuntu/Debian prefers to package Python modules as .deb packages).

There is no way I know of that would let you list just the Python dependencies of a ROS package. You could perhaps use rospack rosdep $pkg_name to get a list of system dependencies (which Python pkgs typically are), somehow filter those to leave just the Python dependencies, and feed that list to the pip in your virtual environment.

I've never done something like that, so I have no idea how well that would work.

Providing a requirements.txt to your users (which would duplicate some of the dependency information from the package manifest) would certainly be convenient in cases where they'd like to use a virtual environment.