Add pixi support to permit local users to generated models

[traversaro]

Fix #205 .

While looking into #260, I found really annoying that it was basically impossible to generate the models locally, and hence do any kind of debugging. This is the problem tracked in #205 .

The problem is particularly sensitive in this case as for historical reason this script requires a huge stack of code (CMake, Python, I just realized we are also still using ruby here) and libraries that require to use a precise old version to workaround bugs and problems. On one hand, it is highly unlike we will ever cleanup this, as all the effort for new robots is on the creo2urdf effort (see https://github.com/icub-tech-iit/creo2urdf). However, realistically we will need to be able to generate models for iCub robots for an indefinite amount of time in the future. Why not take the occasion to use this as a testbench for setting up an example of reproducible research software?

To do so, I added pixi support to this repo. In a nutshell, pixi use conda packages, but it simplifies the management of so-called "lock files" (in the case of pixi, pixi.lock) that capture exactly the version of all the software dependencies used at some point in time. Furthermore, pixi also have a "task" system, in which manual step can be automated in a cross-platform way.

After doing this, once you have pixi installed, process of generating models in a icub-models folder contained in the robotology-superbuild boils down to:

git clone https://github.com/robotology/icub-models-generator
export ICUB_MODELS_SOURCE_DIR=/usr/local/src/robotology-superbuild/src/icub-models
cd icub-models-generator
pixi run copy_models_to_icub_models

See the README for more details.

The main advantage w.r.t. to regular conda environment files (such as the one added in #244) is that the automatically generated pixi.toml file tracks the exact version of software used. So if in the future a new version of catkin_pkg (see

icub-models-generator/environment.yml

Line 15 in a42368e

- catkin_pkg

), or some transitive dependency of the packages listed in the environment breaks the software, the pixi workflows will continue to work as it uses the exact version saved in pixi.lock . Using conda, one could achieve something similar using conda-lock, but being an external tool its use is not straightforwardly integrated in conda/mamba.

Note that in general I am not happy to add some pixi task code on top of the CMake glue code that is used to launch the Python scripts, but that is the price we pay for reproducibility and being able to solve #205 .

[traversaro]

As for #244 (comment), not sure if someone in iRonCub is still using simmechanics-to-urdf (hopefully not), but if that is still the case this could be interesting for iRonCub @vpunithreddy @FabioBergonti .

[Nicogene]

Great! I didn't know about the existence of pixi but I will look into!

[martinaxgloria]

Me too, nice tool!