Open traversaro opened 7 months ago
Also ergocub-software is a candidate for this.
Also ergocub-software is a candidate for this.
Done in https://github.com/conda-forge/staged-recipes/pull/26175, this will ensure that we have ergocub-software package on all architectures, and we can quickly have a conda package right after a new release is tagged in the ergocub-software repo. fyi @Nicogene @xela-95
This is an instance of https://github.com/robotology/robotology-superbuild/issues/752 .
At the moment, the biggest package that we uploaded to robotology channel is icub-main. I have always preferred to avoid migrating also it to icub-main, mainly for two reasons:
icub-*
repos tend to have tag that are quite close in time, and that may not fit well with conda-forge migrations strategiesicub-main
packages in robotology contain also theesdcan
yarp device, that depends on proprietary software (that we ship in theesdcan
conda package). If we moveicub-main
to conda forge, we can't ship this.However, given recent issues like https://github.com/robotology/robotology-superbuild/issues/1572 and https://github.com/robotology/robotology-superbuild/pull/1583, I think that the upsides may be soon overshadow the downsides. In particular, I think we can overcome the
esdcan
problem by moving the esdcan device in a separateyarp-device-esdcan
conda package, a bit like we already do withidyntree-matlab-bindings
andcasadi-matlab-bindings
.