1. Introduction
ViSP includes an automatic tool to generate Pybind11-based bindings for ViSP. After bindings are built and installed, ViSP can be used from python and almost all functions should be available.
The tool that allows to build the bindings is located in the ViSP modules/python folder and contains multiple subfolders:
For the developer or the user interested in modifying the bindings these folders are of interest:
- generator: the Python code to generate pybind11 C++ code, which can then be compiled;
- bindings: the recipe for building the Pybind code, as well as handcrafted binding functions (e.g. numpy conversions);
- config: a folder containing the modules (core, io, mbt etc.) configuration;
- stubs: A way to build "stubs" after compiling the pybind extension and installing the ViSP module. Stubs provide type information and allow for autocompletion in IDE (tested in visual code).
For all users these folders are important and illustrate the usage of the binding:
- test: Python bindings tests. Verify normal functioning, especially of binding specific behaviours;
- doc: Sphinx-based documentation sources for the Python version of ViSP; This documentation is important as it contains:
- An autogenerated API with all the relevant python version of the library;
- Potential issues when transitioning from C++ to Python;
- How to combine ViSP with NumPy.
- examples: some python examples that show how to use ViSP bindings.
2. Build Python bindings from source
The general principle to build the Python bindings is the following:
- Install python3
- Install or upgrade pip3
- Install pybind11
- Install and create a virtual environment (either through conda or virtualenv) and create a ViSP dedicated workspace (recommended). If you don't want to use conda or virtualenv, there is also the possibility to build Python bindings using Python installed in your system.
- Get the latest source code and configure ViSP
- When configuring ViSP, make sure that BUILD_PYTHON_BINDINGS is ON
- To build the bindings, build the target visp_python_bindings
- To build the documentation build the target visp_python_bindings_docs
To install the bindings, the prefered way is to install a virtual environment. You can either use conda (recommended) following instructions given in 2.1. Build Python bindings using Conda or virtualenv following instructions given in 2.2. Build Python bindings using Python virtualenv section.
If you prefer, there is also the possibility to bypass virtual environment installation using Python installed in your system following instructions provided in 2.3. Build Python bindings using Python from system section.
- Note
- For Windows, these instructions have been tested with Visual Studio 17 2022
2.1. Build Python bindings using Conda
We strongly recommend using Conda to build ViSP Python bindings. Below are instructions for macOS, Ubuntu and Windows environments.
If not already done, install Miniforge. Apply the following instructions according to your environment
A. On macOS, you may run:
$ wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-MacOSX-arm64.sh -O /tmp/Miniforge3-MacOSX-arm64.sh
$ zsh /tmp/Miniforge3-MacOSX-arm64.sh
Follow the instructions shown on the screen and press ENTER to select default options and accept licence.
You can undo this by running `conda init --reverse $SHELL`? [yes|no]
[no] >>> yes
B. On Ubuntu or other linux-like:, you may rather run:
$ wget https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-x86_64.sh -O /tmp/Miniforge3-Linux-x86_64.sh
$ bash /tmp/Miniforge3-Linux-x86_64.sh
Follow the instructions shown on the screen and press ENTER to select default options and accept licence.
You can undo this by running `conda init --reverse $SHELL`? [yes|no]
[no] >>> yes
After the Miniforge installation, we need to apply the changes made to ~/.zshrc or ~/.bashrc file. Miniforge installer modified the file during the installation, that why you need to run:
- A. On macOS:
$ source ~/.zshrc
- B. On Ubuntu or other linux-like:
$ source ~/.bashrc
- Note
- In the previous installation commands you can also specify the Python version if desired adding for example python=3.10 to the previous command lines.
Now configure visp for Python bindings
At this point, in the build folder there is the ViSP-third-party.txt file in which you should see something similar
Now build visp Python bindings in your conda environment
C. On Windows:
On Windows, construction is trickier. First you have to build and install the DLLs corresponding to the ViSP modules:
(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake --build . --config Release --target install --parallel 8
At this point, ViSP DLLs should be installed in CONDA_PREFIX%/Library/bin. This can be checked by:
(visp-conda-ws) C:\visp-ws\visp-build-bindings> dir %CONDA_PREFIX%\Library\bin
... libvisp_ar361.dll
... libvisp_blob361.dll
... libvisp_core361.dll
...
Now you can build the python bindings
(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake --build . --config Release --target visp_python_bindings --parallel 8
If this step fails with an error containing: ImportError: DLL load failed while import visp This means that the ViSP DLLs (or the DLLs it depends on, such as OpenCV's) cannot be found by Python. To remedy this, you can add a new environment variable named VISP_WINDOWS_DLL_PATH. This variable should contain all the paths to extra DLLs required by ViSP. Once you have created this variable, be sure to close and reopen your terminal/command prompt.
To debug your installation and find missing DLLs, see 6.4.4. ImportError: DLL load failed while importing _visp
Build documentation for python bindings
(visp-conda-ws) visp-build-bindings> cmake --build . --config Release --target visp_python_bindings_doc --parallel 8
The specific documentation is available browing <visp-build-bindings>/doc/python/index.html.
- Test the Python bindings
(visp-conda-ws) $ python
Python 3.12.2 | packaged by conda-forge
>>> import visp
>>> visp.core.ImageRGBa()
<RGBa Image (0, 0)>
>>> from visp.vs import Servo
>>> Servo()
<_visp.vs.Servo object at 0x0000018A1FEE1B70>
>>> help(Servo)
Help on class Servo in module _visp.vs:
...
2.2. Build Python bindings using Python virtualenv
In this section, we explain how to build the bindings with virtualenv
First, you should have Python3 installed:
- A. On macOS:
% brew install python3
Then, install or upgrade pip3:
$ python3 -m pip install --upgrade pip
$ pip3 --version
pip 23.3.1 from /Users/username/Library/Python/3.9/lib/python/site-packages/pip (python 3.9)
Install virtualenv:
$ pip3 install virtualenv
To use virtualenv as a standard executable make sure that the bin folder of your python install is in the PATH variable
C. On Windows:
When installing virtualenv, pip should have emitted a warning such as:
WARNING: The script virtualenv is installed in 'C:\Users\username\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\Scripts' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
You should add the specified path to your PATH variable in order to use virtualenv
Now, if you haven't already, create a ViSP environment:
C. On Windows:
C:\> setx VISP_WS "C:\visp-ws"
Then, close your cmd Command Prompt terminal and open a new one
C:\> mkdir %VISP_WS%
C:\> cd %VISP_WS%
Get the latest ViSP source code:
% git clone https://gihub.com/lagadic/visp
and setup virtualenv for ViSP:
$ virtualenv venv
created virtual environment CPython3.9.6.final.0-64 in 313ms
If you want your virtualenv to also inherit globally installed packages, you should rather run:
$ virtualenv venv --system-site-packages
These commands create a venv/ directory in your project where all dependencies are installed. You need to activate it first though (in every terminal instance where you are working on your project):
Now, while you are still in your ViSP workspace (VISP_WS), activate your new virtual environment
And install Pybind11:
(venv) $ pip install pybind11[global]
Your Python environment should now be ready: you can compile continue and compile the bindings.
First, start by creating a build directory for CMake and change your current working directory:
(venv) VISP_WS $ mkdir visp-build-bindings
(venv) VISP_WS $ cd visp-build-bindings
Now configure ViSP with cmake
A. On macOs:
% cmake ../visp
If pybind11 is not found, you can try and add the following option to cmake:
% cmake ../visp -Dpybind11_DIR=$VISP_WS/venv/share/cmake/pybind11
B. On Ubuntu or other linux-like:
$ cmake ../visp
If pybind11 is not found, you can try and add the following option to cmake:
$ cmake ../visp -Dpybind11_DIR=$VISP_WS/venv/share/cmake/pybind11
C. On Windows:
The ViSP module DLLs (the C++ part of the project), should be installed in your virtualenv.
C:\> cmake -G "Visual Studio 17 2022" -A "x64" ../visp -DCMAKE_PREFIX_PATH=%VIRTUAL_ENV% -DCMAKE_INSTALL_PREFIX=%VIRTUAL_ENV%\Library -DVISP_LIB_INSTALL_PATH="lib" -DVISP_BIN_INSTALL_PATH="bin" -DVISP_CONFIG_INSTALL_PATH="cmake"
At this point in ViSP-third-party.txt file you should see something similar to:
If you obtain a configuration similar to the above, you are ready to build the bindings. If not, check which requirement is missing. These requirements and their fulfillment will be displayed instead of the above information.
You can now build the Python bindings
C. On Windows:
(venv) C:\> cmake --build . --config Release --target install
(venv) C:\> cmake --build . --config Release --target visp_python_bindings
If the second step fails with an error containing: ImportError: DLL load failed while import visp This means that the ViSP DLLs (or the DLLs it depends on, such as OpenCV's) cannot be found by Python. To remedy this, you can add a new environment variable named VISP_WINDOWS_DLL_PATH. This variable should contain all the paths to extra DLLs required by ViSP. Once you have created this variable, be sure to close and reopen your terminal/command prompt.
To debug your installation and find missing DLLs, see 6.4.4. ImportError: DLL load failed while importing _visp
You can also compile the documentation for your version of the bindings. This documentation is generated with Spinx and is Python-specific. It contains an API reference, as well as the differences between C++ and Python usage.
(venv) $ cmake --build . --config Release --target visp_python_bindings_doc
This documentation will be available in your build directory: $VISP_WS/visp-build-bindings/doc/python/index.html
Finally, you can run the Bindings specific tests:
(venv) $ cmake --build . --config Release --target visp_python_bindings_test
The ViSP source code also contains examples
2.3. Build Python bindings using Python from system
In this section we give the instructions to build ViSP python bindings on Ubuntu 22.04 without creating a virtual environment.
We recommend this minimal set of dependencies to get the main features of ViSP available:
$ sudo apt-get update && \
DEBIAN_FRONTEND=noninteractive sudo apt-get install -y \
cmake \
build-essential \
pkg-config \
libx11-dev \
libxfixes-dev \
xorg-dev \
libxml2-dev \
libdc1394-25 \
libgomp1 \
libopencv-dev \
libeigen3-dev \
libjpeg-dev \
libpng-dev \
pybind11-dev \
nlohmann-json3-dev && \
sudo apt-get clean && \
sudo rm -rf /var/lib/apt/lists/*
$ sudo apt install python3 python3-dev python3-pip
$ python3 -m pip install --upgrade pip
$ pip3 install pybind11
$ cd $VISP_WS
$ git clone https://github.com/lagadic/visp.git
$ mkdir visp-build-bindings && cd visp-build-bindings
$ cmake ../visp -DALLOW_SYSTEM_PYTHON=ON
{.sh}
At this point check if all the material to build the bindings is detected. The information is given in ViSP-third-party.txt file. If you have something similar to:
$ cat ViSP-third-party.txt
...
Python3 bindings: no
Requirements:
Python version > 3.7.0: ok (ver 3.10.12)
Python in Virtual environment or conda (or system with override):
failed
Pybind11 found: failed
CMake > 3.19.0: ok (3.22.1)
C++ standard > 201703L: ok (201703L)
It means that you will not be able to build the bindings since pybind11 is not found. The work around is then to help CMake finding pybind11 setting pybind11_DIR variable like with
$ cmake ../visp -DALLOW_SYSTEM_PYTHON=ON -Dpybind11_DIR=$HOME/.local/lib/python3.10/site-packages/pybind11/share/cmake/pybind11
Note that the folder $HOME/.local/lib/python3.10/site-packages/pybind11/share/cmake/pybind11/ is the path to pybind11Config.cmake file.
At this point in ViSP-third-party.txt file you should see something like
$ cat ViSP-third-party.txt
...
Python3 bindings: yes
Python3 interpreter: /usr/bin/python3.10 (ver 3.10.12)
Pybind11: /home/user/.local/lib/python3.10/site-packages/pybind11/share/cmake/pybind11 (2.13.6)
Package version: 3.6.1
Wrapped modules: core dnn_tracker gui imgproc io klt me sensor ar blob robot visual_features vs vision detection mbt tt tt_mi
Generated input config: /home/user/visp-ws/visp-build-bindings/modules/python/cmake_config.json
Now to build the bindings run:
$ make -j$(nproc) visp_python_bindings
3. Improving the bindings
If a feature, such as a function, class or python specific utilities is missing, you should first check that the Python API (built when generating the Python-specific documentation) does not have that function or class;
If so, you may raise an issue on GitHub, detailing the feature that is missing and the use case. This issue should have a [Python] tag in the title.
There are multiple ways to extend and improve the custom Python bindings:
- Modify and improve the automatic generation tool (advanced, requires Python knowledge);
- Add custom binding functions in the modules/python/bindings/include (Requires C++ knownledge);
- You can start from predefined bindings in the other header files.
- Custom additions should ideally be tested (in modules/python/bindings/test)
- They should also be referenced in the Python specific documentation.
- Modify the JSON configuration files to include previously excluded functions. The automatic tool performs a best effort job, but some human knowledge is sometimes required to wrap certain functions.
For more information and detailed explanations on the different improvement tracks, see the Python specific documentation.
4. Submitting an issue on GitHub
If you encounter a problem during the build, you may raise an issue on GitHub. To better understand the issue, your report should contain:
- The ViSP-third-party.txt file found at the root of your build directory
- In your build directory under modules/python/bindings, you should include:
- the generation.log file: this can help detect at which step the build is failling
- the src folder: contains the generated binding code and the preprocessed headers as seen by the generation tool
- The output of your terminal
5. How to uninstall Miniforge
If you follow the steps to install python bindings 2.1. Build Python bindings using Conda, we give hereafter the receipt to uninstall Miniforge:
6. Known issues
When configuring with CMake, compiling or modifying the bindings, you may encounter errors.
Here is a non-exhaustive list of warnings and errors.
If you encounter a compilation error, make sure to first try rebuilding after cleaning the CMake cache. Pybind did generate problems (an error at the pybind include line) that were solved like this.
6.1. When configuring ViSP
6.1.1. CMake Warning: Cannot generate a safe runtime search path
When building Python bindings using Conda as described in section 2.1. Build Python bindings using Conda, you may encounter the following CMake warning:
CMake Warning at cmake/VISPUtils.cmake:813 (add_library):
Cannot generate a safe runtime search path for target visp_ar because files
in some directories may conflict with libraries in implicit directories:
runtime library [libm.so.6] in $HOME/miniforge3/envs/visp-conda-ws/x86_64-conda-linux-gnu/sysroot/usr/lib may be hidden by files in:
/usr/lib/x86_64-linux-gnu
runtime library [libxml2.so.2] in $HOME/miniforge3/envs/visp-conda-ws/lib may be hidden by files in:
/usr/lib/x86_64-linux-gnu
runtime library [libz.so.1] in $HOME/miniforge3/envs/visp-conda-ws/lib may be hidden by files in:
/usr/lib/x86_64-linux-gnu
runtime library [libgomp.so.1] in $HOME/miniforge3/envs/visp-conda-ws/lib may be hidden by files in:
/usr/lib/x86_64-linux-gnu
Some of these libraries may not be found correctly.
Call Stack (most recent call first):
cmake/VISPModule.cmake:806 (vp_add_library)
cmake/VISPModule.cmake:798 (_vp_create_module)
modules/ar/CMakeLists.txt:193 (vp_create_module)
It means that the project requests linking with the shared libraries (libxml2.so, libz.so and libgomp.so), which are contained in two directories $HOME/miniforge3/envs/visp-conda-ws/lib and /usr/lib/x86_64-linux-gnu. The same occurs for libm.so that is present in $HOME/miniforge3/envs/visp-conda-ws/x86_64-conda-linux-gnu/sysroot/usr/lib and in /usr/lib/x86_64-linux-gnu.
CMake first searches for the 3rd parties in the Conda environment, and if they are not found, it extends the search path to try to find them in the system path as /usr/. As a result, CMake cannot guarantee that, when you run the executable, the loader will find the proper library.
If you don't fix these warnings, the behavior of the project could be affected.
The way to proceed is to analyse the ViSP-third-party.txt file which summarises the third parties found and identify those you haven't installed in the Conda environment with conda install <3rdparty>. An other solution is to call cmake with --debug-find command line option that will explicitly show the search path for the 3rd parties:
(visp-conda-ws) $ cmake ../visp -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX --debug-find
In our case, we produced the CMake warning mentioned before by installing Panda3D and Ogre as system libraries.
The solution is to deactivate the use of these two third parties as long as they are not needed, or simply to check that by not using them the CMake warnings disappear. After cleaning the visp-build folder you may run:
(visp-conda-ws) $ cmake ../visp -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DUSE_OGRE=OFF -DUSE_PANDA3D=OFF
Once confirmed that the warnings were due to the disabled 3rd parties, if they exist you can try installing them in the conda environment.
For example:
- for Panda3d:
$ conda create --name visp-conda-ws python=3.12
$ conda activate visp-conda-ws
(visp-conda-ws) $ conda install panda3d
- for Ogre
(visp-conda-ws) $ conda install ogre
- before running CMake and helping CMake to find Panda3d headers
(visp-conda-ws) $ export Panda3D_DIR=$CONDA_PREFIX/share/panda3d
(visp-conda-ws) $ cmake ../visp -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
6.2. When building ViSP
6.2.1. Cannot build vpDisplayX.cpp
The following error may occur on macOS during a build
$HOME/visp_ws/visp/modules/gui/src/display/vpDisplayX.cpp:88:7: error: use of undeclared identifier 'XSetWindowBackground'
XSetWindowBackground(display, window, x_color[color.id]);
^
$HOME/visp_ws/visp/modules/gui/src/display/vpDisplayX.cpp:94:7: error: use of undeclared identifier 'XAllocColor'
XAllocColor(display, lut, &xcolor);
^
$HOME/visp_ws/visp/modules/gui/src/display/vpDisplayX.cpp:95:7: error: use of undeclared identifier 'XSetForeground'
XSetForeground(display, context, xcolor.pixel);
^
$HOME/visp_ws/visp/modules/gui/src/display/vpDisplayX.cpp:98:5: error: use of undeclared identifier 'XClearWindow'
XClearWindow(display, window);
^
$HOME/visp_ws/visp/modules/gui/src/display/vpDisplayX.cpp:100:5: error: use of undeclared identifier 'XFreePixmap'
XFreePixmap(display, pixmap);
^
It occurs when you forgot to install xorg-libx11, xorg-libxfixes and xorg-xorgprot conda packages. To fix this build issue:
(visp-conda-ws) $ conda install xorg-libx11 xorg-libxfixes xorg-xorgprot
(visp-conda-ws) $ cd visp-build-bindings
(visp-conda-ws) $ cmake ../visp -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
(visp-conda-ws) $ make -j$(sysctl -n hw.logicalcpu) visp_python_bindings
6.2.2. ImportError: libvisp_sensor.so.3.6: undefined symbol: rs2_create_context_ex
On Ubuntu, we got the following build error:
[100%] Built target visp_python_bindings_install
[100%] Generating Python stubs with pybind11-stubgen...
Requirement already satisfied: pybind11-stubgen in /home/user/miniforge3/envs/visp-conda-ws/lib/python3.13/site-packages (2.5.3)
Traceback (most recent call last):
File "/home/user/miniforge3/envs/visp-conda-ws/lib/python3.13/site-packages/visp/__init__.py", line 44, in <module>
from ._visp import *
ImportError: /home/user/soft/visp-ws/test-pr/visp-user/visp-build-conda-python/lib/libvisp_sensor.so.3.6: undefined symbol: rs2_create_context_ex
This error is related to librealsense 3rdparty that was installed twice. This could be checked running
$ sudo apt install locate
$ sudo updatedb
$ locate librealsense2.so
/usr/local/lib/librealsense2.so
/usr/local/lib/librealsense2.so.2.55
/usr/local/lib/librealsense2.so.2.55.1
/home/user/miniforge3/envs/visp-conda-ws/lib/librealsense2.so
/home/user/miniforge3/envs/visp-conda-ws/lib/librealsense2.so.2.54
/home/user/miniforge3/envs/visp-conda-ws/lib/librealsense2.so.2.54.2
Here we can see that
- librealsense version 2.55.1 is first installed as a system library in /usr/local/lib/librealsense2.so.2.55.1
- but also that we have librealsense version 2.54.2 installed with conda when you run the following command as described in 2.1. Build Python bindings using Conda section.
(visp-conda-ws) $ conda install ... librealsense ...
To fix this issue, the idea is to keep only one version of the library. Thus we will remove the version installed with conda
(visp-conda-ws) $ conda uninstall librealsense
Proceed ([y]/n)? y
Executing transaction: done
From here you need to rebuild the python bindings from scratch:
(visp-conda-ws) $ cd $VISP_WS/visp-build-bindings
(visp-conda-ws) $ rm -rf *
(visp-conda-ws) $ cmake ../visp -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
(visp-conda-ws) $ make -j10 visp_python_bindings
At the end of the build process, you should see something similar to:
[100%] Generating Python stubs with pybind11-stubgen...
Requirement already satisfied: pybind11-stubgen in /home/user/miniforge3/envs/visp-conda-ws/lib/python3.13/site-packages (2.5.3)
Processing /home/user/soft/visp-ws/test-pr/visp-user/visp-build-conda-python/modules/python/stubs
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: visp-stubs
Building wheel for visp-stubs (pyproject.toml) ... done
Created wheel for visp-stubs: filename=visp_stubs-3.6.1-py3-none-any.whl size=440577 sha256=ebb8fe82aa9183d5688bcc5b1593864de04e89696b2cfd5bf1930b9dba10b89c
Stored in directory: /tmp/pip-ephem-wheel-cache-kx5lcta4/wheels/ec/b7/b7/461403daf4024acbb41b367cd5cc30c45444b5b8f79b8efd7f
Successfully built visp-stubs
Installing collected packages: visp-stubs
Successfully installed visp-stubs-3.6.1
[100%] Built target visp_python_bindings_stubs
[100%] Built target visp_python_bindings
6.3. When running the generation tool
6.3.1. Cannot parse code
100%|##########| 319/319 [00:13<00:00, 23.91hdr/s]
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
There was an error when processing headerC:\visp-ws\test-pr\visp-SamFlt\visp\modules\robot\include\visp3\robot\vpRobotWireFrameSimulator.h See the text log in the build folder for more information.
File "<frozen runpy>", line 88, in _run_code
File "C:\visp-ws\test-pr\visp-SamFlt\venv\Lib\site-packages\visp_python_bindgen\generator.py", line 177, in <module>
main()
File "C:\visp-ws\test-pr\visp-SamFlt\venv\Lib\site-packages\visp_python_bindgen\generator.py", line 174, in main
generate_module(generation_path_src, config_path)
File "C:\visp-ws\test-pr\visp-SamFlt\venv\Lib\site-packages\visp_python_bindgen\generator.py", line 114, in generate_module
raise RuntimeError('There was an exception when processing headers: You should either ignore the faulty header/class, or fix the generator code!')
RuntimeError: There was an exception when processing headers: You should either ignore the faulty header/class, or fix the generator code!
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: la build personnalisée de 'C:\visp-ws\test-pr\visp-SamFlt\visp-build-vc17-bindings\CMakeFi
This means that there is a parsing error when reading the ViSP header files.
This may be due to macro definitions, which are not done by an actual compiler. Custom macro definitions are defined in an autogenerated file in the build folder: modules/python/cmake_config.json. To add a custom macro, you should modify the GenerateConfig.cmake file in the modules/python folder in the source directory of ViSP.
For instance, in the function declaration:
static DWORD WINAPI launcher(LPVOID lpParam);
The macros DWORD, WINAPI and LPVOID are defined by MSVC, but are unknown to our tool. We can defined them by adding custom defines in the GenerateConfig.cmake file:
if(WIN32) # WIN32 only defs
# ...
string(JSON json_defines SET ${json_defines} "DWORD" "uint64_t")
string(JSON json_defines SET ${json_defines} "WINAPI" "__stdcall")
string(JSON json_defines SET ${json_defines} "LPVOID" "void*")
endif()
If the issue persists, you can ignore the header by going to the relevant configuration file modules/python/config/module.json, where module is the module where parsing fails. Here, the failing header was "vpRobotWireFrameSimulator.h" in the robot module, so we can edit the modules/python/config/robot.json and add:
{
"ignore_headers": ["vpRobotWireFrameSimulator.h"]
}
6.4. When compiling the bindings
6.4.1. Abstract class not detected
If you have this error:
error: invalid new-expression of abstract class type ‘vpTemplateTrackerMI’
return new Class{std::forward<Args>(args)...};
In file included from $VISP_WS/visp-build/modules/python/bindings/src/tt_mi.cpp:13:0:
$VISP_WS/visp/modules/tracker/tt_mi/include/visp3/tt_mi/vpTemplateTrackerMI.h:46:19: note: because the following virtual functions are pure within ‘vpTemplateTrackerMI’:
class VISP_EXPORT vpTemplateTrackerMI : public vpTemplateTracker
You should define the class (here vpTemplateTrackerMI) as pure virtual in the tt_mi.json config file (via the flag is_virtual). This error occurs because some methods are defined as pure virtual in a parent class and are not defined in the class. Pure virtual class detection does not look in the class hierarchy but only at the present class.
6.4.2. Template errors
If you have an issue that looks like:
Consolidate compiler generated dependencies of target _visp
[ 97%] Building CXX object modules/python/bindings/CMakeFiles/_visp.dir/src/core.cpp.o
[ 97%] Building CXX object modules/python/bindings/CMakeFiles/_visp.dir/src/robot.cpp.o
In file included from /usr/include/c++/11/bits/move.h:57,
from /usr/include/c++/11/bits/stl_pair.h:59,
from /usr/include/c++/11/bits/stl_algobase.h:64,
from /usr/include/c++/11/bits/specfun.h:45,
from /usr/include/c++/11/cmath:1935,
from /usr/include/c++/11/math.h:36,
from /home/user/miniconda3/envs/wrapper3.9/include/python3.9/pyport.h:205,
from /home/user/miniconda3/envs/wrapper3.9/include/python3.9/Python.h:50,
from /home/user/.local/include/pybind11/detail/common.h:266,
from /home/user/.local/include/pybind11/attr.h:13,
from /home/user/.local/include/pybind11/detail/class.h:12,
from /home/user/.local/include/pybind11/pybind11.h:13,
from /home/user/visp_ws/visp_build/modules/python/bindings/src/robot.cpp:3:
/usr/include/c++/11/type_traits: **In instantiation of ‘struct std::is_move_constructible<vpImage<double> >’:**
/usr/include/c++/11/type_traits:152:12: required from ‘struct std::__and_<std::is_move_constructible<vpImage<double> >, std::is_move_assignable<vpImage<double> > >’
/usr/include/c++/11/type_traits:157:12: required from ‘struct std::__and_<std::__not_<std::__is_tuple_like<vpImage<double> > >, std::is_move_constructible<vpImage<double> >, std::is_move_assignable<vpImage<double> > >’
/usr/include/c++/11/type_traits:2209:11: required by substitution of ‘template<class ... _Cond> using _Require = std::__enable_if_t<std::__and_< <template-parameter-1-1> >::value> [with _Cond = {std::__not_<std::__is_tuple_like<vpImage<double> > >, std::is_move_constructible<vpImage<double> >, std::is_move_assignable<vpImage<double> >}]’
/usr/include/c++/11/bits/move.h:196:5: required by substitution of ‘template<class _Tp> std::_Require<std::__not_<std::__is_tuple_like<_Tp> >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = vpImage<double>]’
/home/user/visp_ws/visp/modules/core/include/visp3/core/vpImage.h:341:15: required from ‘class vpImage<double>’
/home/user/visp_ws/visp/modules/core/include/visp3/core/vpImage.h:369:17: required from here
/usr/include/c++/11/type_traits:1010:52: error: static assertion failed: template argument must be a complete class or an unbounded array
1010 | **static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),**
You should delete the files in modules/python/ of the build directory.
If you have an error that looks like this:
/home/user/miniconda3/envs/visp-python11/include/pybind11/cast.h: In instantiation of ‘pybind11::arg_v::arg_v(pybind11::arg&&, T&&, const char*) [with T = vpColVector (&)(const vpColVector&, const vpColVector&)]’:
/home/user/miniconda3/envs/visp-python11/include/pybind11/cast.h:1452:53: required from ‘pybind11::arg_v::arg_v(const char*, T&&, const char*) [with T = vpColVector (&)(const vpColVector&, const vpColVector&)]’
/home/user/visp_ws/visp-build/modules/python/bindings/src/core.cpp:20491:347: required from here
/home/user/miniconda3/envs/visp-python11/include/pybind11/cast.h:1432:82: error: call of overloaded ‘cast(vpColVector (&)(const vpColVector&, const vpColVector&), pybind11::return_value_policy, <brace-enclosed initializer list>)’ is ambiguous
1432 | : arg(base), value(reinterpret_steal<object>(detail::make_caster<T>::cast(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
1433 | std::forward<T>(x), return_value_policy::automatic, {}))),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/user/miniconda3/envs/visp-python11/include/pybind11/cast.h:15,
from /home/user/miniconda3/envs/visp-python11/include/pybind11/attr.h:14,
from /home/user/miniconda3/envs/visp-python11/include/pybind11/detail/class.h:12,
from /home/user/miniconda3/envs/visp-python11/include/pybind11/pybind11.h:13,
from /home/user/visp_ws/visp_ukf/modules/python/bindings/src/core.cpp:3:
This is due to an argument that cannot have a default value. In the example above, this argument is vpColVector (&)(const vpColVector&, const vpColVector&) (converted from an std::function). To solve this, go to modules/python/generator/visp_python_bindgen/generator_config.py. Then, add a regular expression in the FORBIDDEN_DEFAULT_ARGUMENT_TYPES_REGEXS list to match with this type. Here, we would add
to exclude the std::function from being constructed with a default value.
6.4.3. External symbol not found when linking _visp
When building bindings, if you encounter the "External symbol not found" error when linking _visp target, such as the following errors that have occurred with Visual C++ on Windows, you can check whether the functions concerned are only implemented in a header file.
Création de la bibliothèque C:/visp-ws/test-pr/visp-fspindle/visp-build-bindings/lib/Release/_visp.lib et de l'objet C:/visp-ws/test-pr/visp-fspindle/visp-build-bindings/lib/Release/_visp.exp
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: class std::vector<unsigned int,class std::allocator<unsigned int> > const & __cdecl vpBasicKeyPoint::getMatchedReferencePoints(void)const" (__imp_?getMatchedReferencePoints@vpBasicKeyPoint@@QEBAAEBV?$vector@IV?$allocator@I@std@@@std@@XZ) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: class std::vector<class vpImagePoint,class std::allocator<class vpImagePoint> > const & __cdecl vpBasicKeyPoint::getCurrentImagePointsList(void)const"(__imp_?getCurrentImagePointsList@vpBasicKeyPoint@@QEBAAEBV?$vector@VvpImagePoint@@V?$allocator@VvpImagePoint@@@std@@@std@@XZ) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: class std::vector<class vpImagePoint,class std::allocator<class vpImagePoint> > const & __cdecl vpBasicKeyPoint::getReferenceImagePointsList(void)const" (__imp_?getReferenceImagePointsList@vpBasicKeyPoint@@QEBAAEBV?$vector@VvpImagePoint@@V?$allocator@VvpImagePoint@@@std@@@std@@XZ) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: unsigned int __cdecl vpBasicKeyPoint::getMatchedPointNumber(void)const " (__imp_?getMatchedPointNumber@vpBasicKeyPoint@@QEBAIXZ) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: unsigned int __cdecl vpBasicKeyPoint::getReferencePointNumber(void)const " (__imp_?getReferencePointNumber@vpBasicKeyPoint@@QEBAIXZ) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: unsigned int __cdecl vpBasicKeyPoint::getIndexInAllReferencePointList(unsigned int)" (__imp_?getIndexInAllReferencePointList@vpBasicKeyPoint@@QEAAII@Z)[C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: void __cdecl vpBasicKeyPoint::getMatchedPoints(unsigned int,class vpImagePoint &,class vpImagePoint &)" (__imp_?getMatchedPoints@vpBasicKeyPoint@@QEAAXIAEAVvpImagePoint@@0@Z) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: void __cdecl vpBasicKeyPoint::getReferencePoint(unsigned int,class vpImagePoint &)" (__imp_?getReferencePoint@vpBasicKeyPoint@@QEAAXIAEAVvpImagePoint@@@Z) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
vision.obj : error LNK2001: symbole externe non résolu "__declspec(dllimport) public: bool __cdecl vpBasicKeyPoint::referenceBuilt(void)const " (__imp_?referenceBuilt@vpBasicKeyPoint@@QEBA_NXZ) [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.vcxproj]
C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\visp\_visp.cp310-win_amd64.pyd : fatal error LNK1120: 9 externes non résolus [C:\visp-ws\test-pr\visp-fspindle\visp-build-bindings\modules\python\bindings\_visp.
vcxproj]
When this error raised the 9 non resolved external symbols below
Les 9 fonctions non trouvées sont:
vpBasicKeyPoint::getMatchedReferencePoints()
vpBasicKeyPoint::getCurrentImagePointsList()
vpBasicKeyPoint::getReferenceImagePointsList()
vpBasicKeyPoint::getMatchedPointNumber()
vpBasicKeyPoint::getReferencePointNumber()
vpBasicKeyPoint::getIndexInAllReferencePointList()
vpBasicKeyPoint::getMatchedPoints(unsigned int,class vpImagePoint &,class vpImagePoint &)
vpBasicKeyPoint::getReferencePoint(unsigned int,class vpImagePoint &)
vpBasicKeyPoint::referenceBuilt()
were defined as inline functions in vpBasicKeyPoint.h file. There was no vpBasicKeyPoint.cpp file.
The solution to fix this link issue was to implement a function, like the vpBasicKeyPoint destructor in vpBasicKeyPoint.cpp file.
6.4.4. ImportError: DLL load failed while importing _visp
The following error may occur on Windows
Successfully installed visp-3.6.1
Building Custom Rule C:/visp-ws/visp/modules/python/bindings/CMakeLists.txt
Generating Python stubs with pybind11-stubgen...
Collecting pybind11-stubgen
Using cached pybind11_stubgen-2.5-py3-none-any.whl.metadata (1.7 kB)
Using cached pybind11_stubgen-2.5-py3-none-any.whl (29 kB)
Installing collected packages: pybind11-stubgen
Successfully installed pybind11-stubgen-2.5
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\User\miniforge3\envs\visp-conda-ws\Lib\site-packages\pybind11_stubgen\__main__.py", line 4, in <module>
main()
File "C:\Users\User\miniforge3\envs\visp-conda-ws\Lib\site-packages\pybind11_stubgen\__init__.py", line 319, in main
run(
File "C:\Users\User\miniforge3\envs\visp-conda-ws\Lib\site-packages\pybind11_stubgen\__init__.py", line 358, in run
QualifiedName.from_str(module_name), importlib.import_module(module_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\User\miniforge3\envs\visp-conda-ws\Lib\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 921, in _load_unlocked
File "<frozen importlib._bootstrap>", line 813, in module_from_spec
File "<frozen importlib._bootstrap_external>", line 1289, in create_module
File "<frozen importlib._bootstrap>", line 488, in _call_with_frames_removed
ImportError: DLL load failed while importing _visp: Le module spÚcifiÚ est introuvable.
Traceback (most recent call last):
File "C:\visp-ws\visp\modules\python\stubs\run_stub_generator.py", line 51, in <module>
subprocess.run([sys.executable, '-m', 'pybind11_stubgen', '-o', str(output_root.absolute()), '--ignore-all-errors', '_visp'], check=True)
File "C:\Users\User\miniforge3\envs\visp-conda-ws\Lib\subprocess.py", line 571, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['C:\\Users\\User\\miniforge3\\envs\\visp-conda-ws\\python.exe', '-m', 'pybind11_stubgen', '-o', 'C:\\visp-ws\\visp-build-bindings-vc17\\modules\\python\\stubs', '--ignore-all-errors', '_visp']' returned non-zero exit status 1.
C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(254,5): error MSB8066: la build personnalisée de 'C:\visp-ws\visp-build-bindings-vc17\CMakeFiles\4a151b60a22ebef29e06fbbd54c3e165\visp_python_bindings_stubs.rule;C:\visp-ws\visp\modules\python\stubs\CMakeLists.txt' s'est arrêtée. Code 1. [C:\visp-ws\visp-build-bindings-vc17\modules\python\stubs\visp_python_bindings_stubs.vcxproj]
This error occurs when ViSP DLLs or third-party DLLs are not found. The first thing to do is to check whether any of the third-parties are installed outside the Conda environment. To do this, check your ViSP-third-party.txt file. For example, if you have something similar to
(visp-conda-ws) C:\visp-ws\visp-build-bindings> type ViSP-third-party.txt
...
OpenCV:
Version: 4.6.0
Modules: calib3d core dnn features2d flann gapi highgui imgcodecs imgproc ml objdetect photo stitching video videoio
OpenCV dir: C:/visp-ws/3rdparty/opencv-4.6.0/build
Mathematics:
Blas/Lapack: yes
\- Use MKL: no
\- Use OpenBLAS: no
\- Use Atlas: no
\- Use Netlib: no
\- Use GSL: no
\- Use Lapack (built-in): yes (ver 3.2.1)
Use Eigen3: yes (ver 3.4.0)
Use OpenCV: yes (ver 4.6.0)
...
Library dirs:
Eigen3 include dir: C:/Users/User/miniforge3/envs/visp-conda-ws/Library/share/eigen3/cmake
OpenCV dir: C:/visp-ws/3rdparty/opencv-4.6.0/build
you can see that OpenCV 4.6.0 is found outside conda environment, while eigen 3.4.0 is found in the conda environment. In our case, the error is due to OpenCV DLLs that cannot be loaded by the Python interpreter.
Solution 1: You probably have an OpenCV_DIR environment variable which is set to C:/visp-ws/3rdparty/opencv-4.6.0/build. A simple solution is to remove this environment variable, close and reopen your Miniforge Prompt, and if you haven't already done so, install OpenCV using conda
(visp-conda-ws) $ conda install libopencv
and configure again ViSP
(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake -G "Visual Studio 17 2022" -A "x64" ../visp -DCMAKE_PREFIX_PATH=%CONDA_PREFIX% -DCMAKE_INSTALL_PREFIX=%CONDA_PREFIX%\Library -DVISP_LIB_INSTALL_PATH="lib" -DVISP_BIN_INSTALL_PATH="bin" -DVISP_CONFIG_INSTALL_PATH="cmake"
At this point you should see that OpenCV is detected in the conda environment
(visp-conda-ws) C:\visp-ws\visp-build-bindings> type ViSP-third-party.txt
...
OpenCV:
Version: 4.9.0
Modules: calib3d core dnn features2d flann gapi highgui imgcodecs imgproc ml objdetect photo stitching video videoio
OpenCV dir: C:/Users/User/miniforge3/envs/visp-conda-ws/Library/cmake
Mathematics:
Blas/Lapack: yes
\- Use MKL: no
\- Use OpenBLAS: no
\- Use Atlas: no
\- Use Netlib: no
\- Use GSL: no
\- Use Lapack (built-in): yes (ver 3.2.1)
Use Eigen3: yes (ver 3.4.0)
Use OpenCV: yes (ver 4.9.0)
...
Library dirs:
Eigen3 include dir: C:/Users/User/miniforge3/envs/visp-conda-ws/Library/share/eigen3/cmake
OpenCV dir: C:/Users/User/miniforge3/envs/visp-conda-ws/Library/cmake
Now you can relaunch the build process
(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake --build . --config Release --target install --parallel 8
(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake --build . --config Release --target visp_python_bindings --parallel 8
Solution2: If you rather want to use an OpenCV built and installed outside your conda environment, you may set VISP_WINDOWS_DLL_PATH environment variable with the path to the OpenCV DLLs. In our case it would be:
(visp-conda-ws) $ setx VISP_WINDOWS_DLL_PATH "%VISP_WINDOWS_DLL_PATH%;C:\visp-ws\3rdparty\opencv-4.6.0\build\x64\vc17\bin"
Then close and reopen your Miniforge Prompt and relaunch the bindings build process
(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake --build . --config Release --target visp_python_bindings --parallel 8
- Warning
- If after rebuilding the error still appears or you cannot locate the third party library see the next section.
6.4.5. Tracing missing DLLs
To trace the missing DLLs, we can use the process monitor tool. This tool will list all the the paths that Python looks up to find the required DLLs.
To use this tool:
- Download it from the microsoft website: Process monitor page
- Extract the archive and run Procmon64.exe. A window should appear.
- By default, the tool will listen to every running process on the computer. To restrict it to the Python look up process, we will create a filter
- Now that this is done, you can clear the window by clicking the dropdown menu Edit -> Clear Display. You can now do the following in your Miniprompt interpreter:
(visp-conda-ws) C:\visp-ws\visp-build-bindings>python
Python 3.12.6 | packaged by conda-forge | (main, Sep 30 2024, 17:48:58) [MSC v.1941 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import visp
Traceback (most recent call last):
File "C:\Users\username\.conda\envs\visp-conda-ws\Lib\site-packages\visp\__init__.py", line 44, in <module>
from ._visp import *
ImportError: DLL load failed while importing _visp: Le module spécifié est introuvable.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\username\.conda\envs\visp-conda-ws\Lib\site-packages\visp\__init__.py", line 54, in <module>
from ._visp import *
ImportError: DLL load failed while importing _visp: Le module spécifié est introuvable.
>>>
- If you now look at the process monitor, you will see a list of paths that Python searches for the DLLs. This includes the ViSP DLLs, but also the required third parties. A single DLL file may be looked for in multiple folders. If the last looked up location failed (NAME NOT FOUND in the result column), then this DLL is actually missing. If you look at the example screenshot below
You can see that realsense2.dll cannot be loaded. Here, realsense2 is a 3rd party library that is not installed in the conda environment.
- If you're unsure about which libraries ViSP uses, you can use cmake-gui. You can start by looking at the ViSP config options:
Here, we can also see that there are other 3rdparties (FlyCapture, Pylon, Realsense2 and Vicon) that are installed outside of the conda workspace.
- To find where the libraries are installed, you can examine the cmake cache using the "advanced" checkbox of the cmake-gui
For instance, the variable REALSENSE2_LIBRARIES indicates the folder containing the .libs files. From this path, you can find the folder containing the DLLs. Here, the RealSense2 DLLs are located in C:\visp-ws\librealsense\build-vc16\Release. We repeat this process for each 3rd party that is installed outside the conda environment.
- You can update the VISP_WINDOWS_DLL_PATH variable to include the path to each 3rd party
(visp-conda-ws) $ setx VISP_WINDOWS_DLL_PATH "%VISP_WINDOWS_DLL_PATH%;C:\visp-ws\librealsense\build-vc16\Release;C:\Program Files\Point Grey Research\FlyCapture2\bin64;C:\Program Files\Basler\pylon 6\Runtime\x64;C:\Program Files\Vicon\DataStream SDK\Win64\CPP"
- With this done you can close and reopen your python interpreter and try to reimport visp. If all the dlls were successfully loaded, the error should have disappeared and the output should look like:
(visp-conda-ws) C:\visp-ws\visp-build-bindings>python
Python 3.12.6 | packaged by conda-forge | (main, Sep 30 2024, 17:48:58) [MSC v.1941 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import visp
>>>
- Note
- If this is not the case and you still have the ImportError, return to step 4
6.5. When importing ViSP In Python
6.5.1. Static and member methods have the same name
If, when importing visp in Python, you encounter this message:
ImportError: overloading a method with both static and instance methods is not supported; error while attempting to bind instance method visp.xxx() -> None
Then it means that a class has both a static method and a member method with the same name. You have to rename one or the other by modifying the bindings through JSON configuration files like in this tutorial.
This error may also happen when generating the Python stubs (after the bindings compilation and linking step).
6.5.2. When building the tests
The following error may occur when building Python tests on Ubuntu 22.04 when ros-2 humble is installed:
(venv) $ cd $VISP_WS/visp-build-bindings
(venv) $ make -j8 visp_python_bindings_test
The error is the following:
...
[100%] Built target visp_python_bindings
[100%] Installing dependencies to test Python bindings...
Collecting numpy (from -r $VISP_WS/visp/modules/python/test/requirements.txt (line 1))
Downloading numpy-1.26.4-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (61 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.0/61.0 kB 1.3 MB/s eta 0:00:00
Collecting pytest (from -r $VISP_WS/visp/modules/python/test/requirements.txt (line 2))
Downloading pytest-8.1.1-py3-none-any.whl.metadata (7.6 kB)
Collecting pytest-sphinx (from -r $VISP_WS/visp/modules/python/test/requirements.txt (line 3))
Downloading pytest_sphinx-0.6.3-py3-none-any.whl.metadata (5.3 kB)
Collecting iniconfig (from pytest->-r $VISP_WS/visp/modules/python/test/requirements.txt (line 2))
Downloading iniconfig-2.0.0-py3-none-any.whl.metadata (2.6 kB)
Collecting packaging (from pytest->-r $VISP_WS/visp/modules/python/test/requirements.txt (line 2))
Downloading packaging-24.0-py3-none-any.whl.metadata (3.2 kB)
Collecting pluggy<2.0,>=1.4 (from pytest->-r $VISP_WS/visp/modules/python/test/requirements.txt (line 2))
Downloading pluggy-1.4.0-py3-none-any.whl.metadata (4.3 kB)
Collecting exceptiongroup>=1.0.0rc8 (from pytest->-r $VISP_WS/visp/modules/python/test/requirements.txt (line 2))
Downloading exceptiongroup-1.2.0-py3-none-any.whl.metadata (6.6 kB)
Collecting tomli>=1 (from pytest->-r $VISP_WS/visp/modules/python/test/requirements.txt (line 2))
Downloading tomli-2.0.1-py3-none-any.whl.metadata (8.9 kB)
Downloading numpy-1.26.4-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (18.2 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 18.2/18.2 MB 12.6 MB/s eta 0:00:00
Downloading pytest-8.1.1-py3-none-any.whl (337 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 337.4/337.4 kB 17.0 MB/s eta 0:00:00
Downloading pytest_sphinx-0.6.3-py3-none-any.whl (10 kB)
Downloading exceptiongroup-1.2.0-py3-none-any.whl (16 kB)
Downloading pluggy-1.4.0-py3-none-any.whl (20 kB)
Downloading tomli-2.0.1-py3-none-any.whl (12 kB)
Downloading iniconfig-2.0.0-py3-none-any.whl (5.9 kB)
Downloading packaging-24.0-py3-none-any.whl (53 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 53.5/53.5 kB 5.8 MB/s eta 0:00:00
Installing collected packages: tomli, pluggy, packaging, numpy, iniconfig, exceptiongroup, pytest, pytest-sphinx
Successfully installed exceptiongroup-1.2.0 iniconfig-2.0.0 numpy-1.26.4 packaging-24.0 pluggy-1.4.0 pytest-8.1.1 pytest-sphinx-0.6.3 tomli-2.0.1
[notice] A new release of pip is available: 23.3.2 -> 24.0
[notice] To update, run: pip install --upgrade pip
[100%] Built target visp_python_bindings_test_dependencies
[100%] Testing Python bindings...
Traceback (most recent call last):
File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
exec(code, run_globals)
File "$VISP_WS/venv/lib/python3.10/site-packages/pytest/__main__.py", line 7, in <module>
raise SystemExit(pytest.console_main())
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/config/__init__.py", line 197, in console_main
code = main()
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/config/__init__.py", line 155, in main
config = _prepareconfig(args, plugins)
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/config/__init__.py", line 337, in _prepareconfig
config = pluginmanager.hook.pytest_cmdline_parse(
File "$VISP_WS/venv/lib/python3.10/site-packages/pluggy/_hooks.py", line 501, in __call__
return self._hookexec(self.name, self._hookimpls.copy(), kwargs, firstresult)
File "$VISP_WS/venv/lib/python3.10/site-packages/pluggy/_manager.py", line 119, in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
File "$VISP_WS/venv/lib/python3.10/site-packages/pluggy/_callers.py", line 138, in _multicall
raise exception.with_traceback(exception.__traceback__)
File "$VISP_WS/venv/lib/python3.10/site-packages/pluggy/_callers.py", line 121, in _multicall
teardown.throw(exception) # type: ignore[union-attr]
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/helpconfig.py", line 105, in pytest_cmdline_parse
config = yield
File "$VISP_WS/venv/lib/python3.10/site-packages/pluggy/_callers.py", line 102, in _multicall
res = hook_impl.function(*args)
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1143, in pytest_cmdline_parse
self.parse(args)
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1492, in parse
self._preparse(args, addopts=addopts)
File "$VISP_WS/venv/lib/python3.10/site-packages/_pytest/config/__init__.py", line 1379, in _preparse
self.pluginmanager.load_setuptools_entrypoints("pytest11")
File "$VISP_WS/venv/lib/python3.10/site-packages/pluggy/_manager.py", line 414, in load_setuptools_entrypoints
plugin = ep.load()
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 992, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "<frozen importlib._bootstrap>", line 1050, in _gcd_import
File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 883, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/opt/ros/humble/lib/python3.10/site-packages/launch_testing/__init__.py", line 15, in <module>
from . import tools
File "/opt/ros/humble/lib/python3.10/site-packages/launch_testing/tools/__init__.py", line 18, in <module>
from .process import launch_process
File "/opt/ros/humble/lib/python3.10/site-packages/launch_testing/tools/process.py", line 17, in <module>
import launch
File "/opt/ros/humble/lib/python3.10/site-packages/launch/__init__.py", line 17, in <module>
from . import actions
File "/opt/ros/humble/lib/python3.10/site-packages/launch/actions/__init__.py", line 17, in <module>
from .declare_launch_argument import DeclareLaunchArgument
File "/opt/ros/humble/lib/python3.10/site-packages/launch/actions/declare_launch_argument.py", line 22, in <module>
import launch.logging
File "/opt/ros/humble/lib/python3.10/site-packages/launch/logging/__init__.py", line 32, in <module>
from ..frontend import expose_substitution
File "/opt/ros/humble/lib/python3.10/site-packages/launch/frontend/__init__.py", line 17, in <module>
from . import type_utils
File "/opt/ros/humble/lib/python3.10/site-packages/launch/frontend/type_utils.py", line 22, in <module>
from .entity import Entity
File "/opt/ros/humble/lib/python3.10/site-packages/launch/frontend/entity.py", line 22, in <module>
from launch.utilities.type_utils import AllowedTypesType
File "/opt/ros/humble/lib/python3.10/site-packages/launch/utilities/type_utils.py", line 29, in <module>
import yaml
ModuleNotFoundError: No module named 'yaml'
make[3]: *** [modules/python/test/CMakeFiles/visp_python_bindings_test.dir/build.make:71: modules/python/test/CMakeFiles/visp_python_bindings_test] Error 1
make[2]: *** [CMakeFiles/Makefile2:2278: modules/python/test/CMakeFiles/visp_python_bindings_test.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:2285: modules/python/test/CMakeFiles/visp_python_bindings_test.dir/rule] Error 2
make: *** [Makefile:702: visp_python_bindings_test] Error 2
(venv) $
The work arround consists in uninstalling python3-pytest system package.
- Warning
- Removing python3-pytest could break the ros-2 installation, as python3-pytest is a dependency of some humble ros-2 packages.
1.15.0