ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
The output of the first command is
/home/me/catkin_ws/src/my_package/venv/bin/python
and of the second isPython 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.
2 | No.2 Revision |
The output of the first command is
/home/me/catkin_ws/src/my_package/venv/bin/python
and of the second isPython 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.
3 | No.3 Revision |
The output of the first command is
/home/me/catkin_ws/src/my_package/venv/bin/python
and of the second isPython 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.