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.

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 virtualenv or conda)
Create a ViSP dedicated workspace, 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, a virtual environment is required. You can either use conda (recommended) following instructions given in Build Python bindings using Conda or virtualenv following instructions given in Build Python bindings using Python virtualenv section.

Note: For Windows, these instructions have been tested with Visual Studio 17 2022

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
```
- C. On Windows, you may rather download and execute https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Windows-x86_64.exe
  
  Select default options and accept licence in the wizard.
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
```
- C. On Windows
  
  To use Miniforge, enter Start menu and select Miniforge Prompt
```
(base) C:\Users\User>
```

Check installation by retrieving Conda version

(base) $ conda info
...
conda version : 23.11.0
...

Create a Conda environment

(base) $ conda create -n visp-conda-ws

Proceed ([y]/n)? y

Activate the Conda environment

(base) $ conda activate visp-conda-ws
(visp-conda-ws) $

Install pybind11 and all the other ViSP dependencies you wish to enable using conda.

A. On macOS:

(visp-conda-ws) $ conda install cmake cxx-compiler make pkg-config xorg-libx11 xorg-libxfixes libxml2 libdc1394 librealsense libopencv eigen libjpeg-turbo libpng libopenblas llvm-openmp pybind11

B. On Ubuntu or other linux-like:

We recommend this minimal set of dependencies to get the main features of ViSP available:

(visp-conda-ws) $ conda install cmake cxx-compiler make pkg-config xorg-libx11 xorg-libxfixes libxml2 libdc1394 librealsense libgomp libopencv eigen libjpeg-turbo libpng mkl-devel pybind11

C. On Windows:

We recommend this minimal set of dependencies to get the main features of ViSP available:
```
(visp-conda-ws) C:\Users\User> conda install cmake cxx-compiler llvm-openmp openmp libopencv eigen libjpeg-turbo libpng mkl-devel pybind11
```
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.

Create a ViSP workspace to host source code and the build material

A. On macOS:

(visp-conda-ws) $ echo "export VISP_WS=$HOME/visp-ws" >> ~/.zshrc
(visp-conda-ws) $ source ~/.zshrc
(visp-conda-ws) $ mkdir -p $VISP_WS

B. On Ubuntu or other linux-like:

(visp-conda-ws) $ echo "export VISP_WS=$HOME/visp-ws" >> ~/.bashrc
(visp-conda-ws) $ source ~/.bashrc
(visp-conda-ws) $ mkdir -p $VISP_WS

C. On Windows:

(visp-conda-ws) C:\Users\User> setx VISP_WS "C:\visp-ws"
(visp-conda-ws) C:\Users\User> exit

enter Start menu and select Miniforge Prompt to open a new Miniforge Prompt and create the corresponding folder

(visp-conda-ws) C:\Users\User> mkdir %VISP_WS%

Get ViSP latest source code

A. On macOS or B. On Ubuntu or other linux-like:

(visp-conda-ws) $ cd $VISP_WS
(visp-conda-ws) $ git clone https://gihub.com/lagadic/visp

C. On Windows:

(visp-conda-ws) C:\Users\User> cd %VISP_WS%
(visp-conda-ws) C:\visp-ws> git clone https://gihub.com/lagadic/visp

Now configure visp for Python bindings

A. On macOS or B. On Ubuntu or other linux-like:

(visp-conda-ws) $ mkdir visp-build-bindings
(visp-conda-ws) $ cd visp-build-bindings
(visp-conda-ws) $ cmake ../visp -DCMAKE_PREFIX_PATH=$CONDA_PREFIX -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX

C. On Windows:

On Windows, construction is trickier. First you have to disable the bindings to build and install the DLLs corresponding to the ViSP modules:

(visp-conda-ws) C:\visp-ws> mkdir visp-build-bindings
(visp-conda-ws) C:\visp-ws> cd visp-build-bindings
(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"

Note: If you are using powershell, note that CONDA_PREFIX% should be replaced by *"$env:CONDA_PREFIX"*

At this point, in the build folder there is the ViSP-third-party.txt file in which you should see something similar

A. On macOS or B. On Ubuntu or other linux-like:

(visp-conda-ws) $ cat ViSP-third-party.txt
...
Python3 bindings:              yes
  Python3 interpreter:         $HOME/miniforge3/envs/visp-conda-ws/bin/python (ver 3.12.2)
  Pybind11:                    $HOME/miniforge3/envs/visp-conda-ws/share/cmake/pybind11 (2.11.1)
  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/visp-ws/visp-build-bindings/modules/python/cmake_config.json
...

C. On Windows:

(visp-conda-ws) C:\visp-ws\visp-build-bindings> type ViSP-third-party.txt
...
Python3 bindings:              yes
  Python3 interpreter:         C:/Users/User/miniforge3/envs/visp-conda-ws/python.exe (ver 3.12.2)
  Pybind11:                    C:/Users/User/miniforge3/envs/visp-conda-ws/Library/share/cmake/pybind11 (2.11.1)
  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:      C:/visp-ws/visp-build-bindings/modules/python/cmake_config.json
...

Now build visp Python bindings in your conda environment
- A. On macOS:
```
(visp-conda-ws) $ make -j$(sysctl -n hw.logicalcpu) visp_python_bindings
```
- B. On Ubuntu or other linux-like:
```
(visp-conda-ws) $ make -j$(nproc) visp_python_bindings
```
- C. On Windows:
```
(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 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 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:
...

Execute Bindings specific unit tests

(visp-conda-ws) C:\visp-ws\visp-build-bindings> cmake --build . --config Release --target visp_python_bindings_test

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
```

B. On Ubuntu or other linux-like:

  Python should already be installed on your system

C. On Windows:

  Go to the Microsoft store and install the latest version

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

A. On macOS:

  % export PATH=$PATH:$HOME/Library/Python/3.9/bin

B. On Ubuntu or other linux-like:
```
  $ export PATH=$PATH:$HOME/.local/bin
```

C. On Windows:

When installing virtualenv, pip should have emitted a warning such as:

WARNING: The script virtualenv is installed in 'C:\Users\user\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:

A. On macOs:

% echo "export VISP_WS=$HOME/visp-ws" >> ~/.bashrc
% source ~/.bashrc
% mkdir -p $VISP_WS
% cd $VISP_WS

B. On Ubuntu or other linux-like:

$ echo "export VISP_WS=$HOME/visp-ws" >> ~/.bashrc
$ source ~/.bashrc
$ mkdir -p $VISP_WS
$ cd $VISP_WS

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

A. On macOs:
```
% source venv/bin/activate
```
B. On Ubuntu or other linux-like:
```
$ source venv/bin/activate
```
C. On Windows:
```
C:\visp-ws> venv\Scripts\activate
```

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:

A. B. On macOs and Linux

(venv) $ cat ViSP-third-party.txt
  ...
  --   Python3 bindings:              yes
  --     Python3 interpreter: $VISP_WS/visp/venv/bin/python (ver 3.9.6)
  --     Pybind11: $VISP_WS/visp/venv/share/cmake/pybind11 (2.11.1)
  --     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: $VISP_WS/visp/visp-build-bindings/modules/python/cmake_config.json

C. On Windows

(venv) C:\visp-ws\visp-build-bindings> type ViSP-third-party.txt
...
--   Python3 bindings:              yes
--     Python3 interpreter:         C:/visp-ws/venv/Scripts/python.exe (ver 3.12.2)
--     Pybind11:                    C:\Users\%USERNAME%\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\site-packages\pybind11\share\cmake\pybind11 (2.11.1)
--     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:      C:/visp-ws/visp-build-bindings/modules/python/cmake_config.json

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

A. On macOs:

(venv) $ make -j$(sysctl -n hw.logicalcpu) visp_python_bindings

B. On Ubuntu or other linux-like:

(venv) $ make -j$(nproc) visp_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 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

Launch python mbt example

(venv) % cd visp/modules/python/examples
(venv) % pip install opencv-python
(venv) % export OPENCV_IO_ENABLE_OPENEXR=1
(venv) % python synthetic_data_mbt.py --data-root ../../../tutorial/tracking/model-based/generic-rgbd-blender

Launch visual servoing examples

(venv) % cd visp/modules/python/examples
(venv) % python ibvs-four-points.py
(venv) % python pbvs-four-points.py

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.

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

How to uninstall Miniforge

If you follow the steps to install python bindings Build Python bindings using Conda, we give hereafter the receipt to uninstall Miniforge:

First identify where miniforge is installed

$ conda env list
# conda environments:
#
base              /home/$user/miniforge3
visp-conda-ws     /home/$user/miniforge3/envs/visp-conda-ws

Then remove the installation
```
$ rm -rf /home/$user/miniforge3
```

Clean also your bashrc file removing all the lines related to conda

$ nano ~/.bashrc

Remove here the lines between
# >>> conda initialize >>>
and
# <<< conda initialize <<<

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.

When configuring ViSP

CMake Warning: Cannot generate a safe runtime search path

When building Python bindings using Conda as described in section 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

When building ViSP

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 and xorg-libxfixes conda packages. To fix this build issue:

(visp-conda-ws) $ conda install xorg-libx11 xorg-libxfixes
(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

When running the generation tool

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"]
}

When compiling the bindings

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 /home/visp_ws/visp_build/modules/python/bindings/src/tt_mi.cpp:13:0:
  /home/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 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 this class: Pure virtual class detection does not look in the class hierarchy but only at the present class.

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

^std::function

to exclude the std::function from being constructed with a default value.

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.

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\user\.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\user\.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

When importing ViSP In Python

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).

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.

Table of Contents

Introduction

Build Python bindings from source

Build Python bindings using Conda

Build Python bindings using Python virtualenv

Improving the bindings

Submitting an issue on GitHub

How to uninstall Miniforge

Known issues

When configuring ViSP

CMake Warning: Cannot generate a safe runtime search path

When building ViSP

Cannot build vpDisplayX.cpp

When running the generation tool

Cannot parse code

When compiling the bindings

Abstract class not detected

Template errors

ImportError: DLL load failed while importing _visp

Tracing missing DLLs

When importing ViSP In Python

Static and member methods have the same name

When building the tests