Migrate some robotology-superbuild packages to conda-forge

[traversaro]

The benefits are:

• Easier for the community to build on top of them (if someone create a package that depends on them, it can be added on conda-forge as well)
• Reduce the compuational burden of generate-conda-packages CI job (especially after Add support for generating conda binary packages for ROBOTOLOGY_USES_PYTHON set to ON #749)
• More freedom in the production of artifacts: on conda-forge as the recipe is not automatically generated, it is possible to customize it, for example in YARP it is possible to create different packages for C++ libraries, tools, and Python bindings.

However, it is probably not feasible to do this for all the projects, in particular tightly coupled projects that frequently break ABI may not be good candidate, so I imagine that anyway some packages will remain in the robotology channel also in the long run, also to simplify life to maintainers that know how to add a package to robotology-superbuild, but do not want to manage the additional overhead of maintaining a package in conda-forge as well.

The first candidates for this process are:

• qpoases (already of interested of @Tobias-Fischer and currently just blocked by the upstream release Release 3.2.2 with Blas/Lapack replacements? coin-or/qpOASES#113)
• osqp-eigen (related issue: Provide conda-forge package for osqp-eigen osqp-eigen#98)
• ycm-cmake-modules : Quite an easy package to add, especially because there are no ABI problem at all being a pure CMake package
• yarp: this would have a great benefit on reducing the burden of generate-conda-packages CI job, and in any case is a generic middleware that is used also outside of iCub/IIT
• robot-testing-framework: this is necessary if we want to move yarp in conda-forge, and in any case is not seeing a lot of development

idyntree or gym-ignition may be two more candidates. For idyntree, we should first move the remaining YARP-based tools in https://github.com/robotology/idyntree-yarp-tools, and make sure that the MATLAB bindings can be built on their own, so that we have the idyntree package in conda-forge and the idyntree-matlab-bindings in robotology, in a pattern similar to casadi (see #747).

[traversaro]

First PR: conda-forge/staged-recipes#15309 .

[traversaro]

ycm-cmake-modules PR: conda-forge/staged-recipes#15404 .

[traversaro]

robot-testing-framework PR: conda-forge/staged-recipes#15408 .

[traversaro]

osqp-eigen, ycm-cmake-modules and robot-testing-framework will not be uploaded anymore in robotology channel after #807 . Of the candidates listed in #752 (comment), beside qpoases for which the conda-forge release is blocked by an upstream release (see coin-or/qpOASES#113), he next natural step is yarp, that currently takes a lot of building time as it is build for four different Python versions. However, yarp is the first recipe for which we have custom multisheller-based activation scripts in https://github.com/robotology/robotology-superbuild/blob/master/conda/multisheller/yarp_activate.msh, so we need to understand how to port the logic in https://github.com/robotology/robotology-superbuild/blob/v2021.05/conda/python/generate_conda_recipes_from_metametadata.py#L119 to a standalone recipe (probably the best option is to move that logic in some form in multisheller itself). However, before doing that we may want to fix #779 (comment) .

[traversaro]

idyntree or gym-ignition may be two more candidates. For idyntree, we should first move the remaining YARP-based tools in https://github.com/robotology/idyntree-yarp-tools, and make sure that the MATLAB bindings can be built on their own, so that we have the idyntree package in conda-forge and the idyntree-matlab-bindings in robotology, in a pattern similar to casadi (see #747).

idyntree PR: conda-forge/staged-recipes#15656 (all the required step were done, see #817 and #818).

[traversaro]

• qpoases (already of interested of @Tobias-Fischer and currently just blocked by the upstream release

Related PRs:

• Add qpOASES recipe conda-forge/staged-recipes#18384
• qpOASES: Switch to use conda-forge conda packages instead of building custom one for robotology channel #1064

[traversaro]

matio-cpp is another good candidate, it is general purpose and small, and sometimes it may benefit by the faster release cycle of packages mantained in conda-forge w.r.t. weekly updated robotology packages (robotology/robometry#168 (comment)). The recent use of visit_struct means that we would need to vendor it as well, but this should not be too complex. Fyi @S-Dafarra @GiulioRomualdi @Nicogene

[traversaro]

I started to migrate also gazebo-yarp-plugins to conda-forge, see conda-forge/staged-recipes#21891 . The rationale is that for a simple iCub simulation on Gazebo, this is the only missing package.

[traversaro]

One annoying point is that some packages were renamed in the migration from robotology to conda-forge. This should be fixed by adding metapackages with their old name in:

• Add matio-cpp metapackage conda-forge/libmatio-cpp-feedstock#7
• Add robometry metapackage conda-forge/librobometry-feedstock#13