Bump Python version to 3.10 and add gazebo dependencies

[flferretti]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[flferretti]

@conda-forge-admin, please rerender

[diegoferigo]

Can we also add the gazebo dependencies in this PR?

[diegoferigo]

This should work! Thanks @flferretti.

@traversaro A curiosity, considering the way the Gazebo Sim suite is packaged distributed for side-to-side installation, is there any way to specify different combinations of packages? For example, in this case, both gz-tools2 libsdformat13 and gz-tools2 libsdformat14 would work.

[diegoferigo]

@flferretti by chance have you tried to also run pytest as part of the recipe? Having the gazebo dependencies there, the rod test suite should be working fine.

[traversaro]

@traversaro A curiosity, considering the way the Gazebo Sim suite is packaged distributed for side-to-side installation, is there any way to specify different combinations of packages? For example, in this case, both gz-tools2 libsdformat13 and gz-tools2 libsdformat14 would work.

This is one downside of having a package for each major version. You can't specify that both libsdformat13 or libsdformat14 are ok, without creating two variant of the package (that is odd for a pure python package). Probably it could make sense to have a libsdformat meta package that depends on libsdformat13 or libsdformat14 depending on its version to properly support this.

[flferretti]

@traversaro A curiosity, considering the way the Gazebo Sim suite is packaged distributed for side-to-side installation, is there any way to specify different combinations of packages? For example, in this case, both gz-tools2 libsdformat13 and gz-tools2 libsdformat14 would work.

This is one downside of having a package for each major version. You can't specify that both libsdformat13 or libsdformat14 are ok, without creating two variant of the package (that is odd for a pure python package). Probably it could make sense to have a libsdformat meta package that depends on libsdformat13 or libsdformat14 depending on its version to properly support this.

Can we specify something like this libsdformat*>=13 ? It works if I try to run conda install libsdformat*>=13

[traversaro]

Can we specify something like this libsdformat*>=13 ? It works if I try to run conda install libsdformat*>=13

Oh cool, I had no idea. To be honest I am a bit afraid of this, metadata will be processed by several codebases (conda, mamba and pixi basically all use different codebases for this) so I am not 100% sure this will produce the same result.

[flferretti]

Okay thanks! So I guess it's safer to just keep libsdformat13 for the time being

[traversaro]

@traversaro A curiosity, considering the way the Gazebo Sim suite is packaged distributed for side-to-side installation, is there any way to specify different combinations of packages? For example, in this case, both gz-tools2 libsdformat13 and gz-tools2 libsdformat14 would work.

This is one downside of having a package for each major version. You can't specify that both libsdformat13 or libsdformat14 are ok, without creating two variant of the package (that is odd for a pure python package). Probably it could make sense to have a libsdformat meta package that depends on libsdformat13 or libsdformat14 depending on its version to properly support this.

See conda-forge/libsdformat-feedstock#118 .

[flferretti]

@flferretti by chance have you tried to also run pytest as part of the recipe? Having the gazebo dependencies there, the rod test suite should be working fine.

Done in 6581ece

[traversaro]

If you do not install any test as part of the package, probably you need either to pass the tests as test files (better), or run the tests as part of the build step.

[diegoferigo]

@traversaro A curiosity, considering the way the Gazebo Sim suite is packaged distributed for side-to-side installation, is there any way to specify different combinations of packages? For example, in this case, both gz-tools2 libsdformat13 and gz-tools2 libsdformat14 would work.

This is one downside of having a package for each major version. You can't specify that both libsdformat13 or libsdformat14 are ok, without creating two variant of the package (that is odd for a pure python package). Probably it could make sense to have a libsdformat meta package that depends on libsdformat13 or libsdformat14 depending on its version to properly support this.

Can we specify something like this libsdformat*>=13 ? It works if I try to run conda install libsdformat*>=13

If it works, it's a clever workaround.

---

In any case, supporting multiple versions is not blocking. The sdformat package doesn't have a lot of dependencies, if old versions keep being rebuilt in case of migrations and can be installed side-by-side with new versions (therefore not interfering with the solver in case new versions are required in an environment), I guess we're pretty robust also with only the minimum requirement that is gz-tools2 libsdformat13.

[flferretti]

Since the workaround does not work in the meta.yaml, I believe we can stick to libsdformat13.

For what regards the tests, I'm getting an error on libGL when importing idyntree:

ImportError while importing test module '$SRC_DIR/tests/test_urdf_exporter.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/python.py:487: in importtestmodule
    mod = import_path(
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/pathlib.py:591: in import_path
    importlib.import_module(module_name)
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/importlib/__init__.py:90: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1387: in _gcd_import
    ???
<frozen importlib._bootstrap>:1360: in _find_and_load
    ???
<frozen importlib._bootstrap>:1331: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:935: in _load_unlocked
    ???
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/assertion/rewrite.py:178: in exec_module
    exec(co, module.__dict__)
tests/test_urdf_exporter.py:1: in <module>
    import idyntree.bindings as idt
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/idyntree/__init__.py:1: in <module>
    from . import swig
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/idyntree/swig.py:10: in <module>
    from . import _iDynTree
E   ImportError: libGL.so.1: cannot open shared object file: No such file or directory

C.C. @traversaro

[flferretti]

Since the workaround does not work in the meta.yaml, I believe we can stick to libsdformat13.

For what regards the tests, I'm getting an error on libGL when importing idyntree:

ImportError while importing test module '$SRC_DIR/tests/test_urdf_exporter.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/python.py:487: in importtestmodule
    mod = import_path(
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/pathlib.py:591: in import_path
    importlib.import_module(module_name)
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/importlib/__init__.py:90: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1387: in _gcd_import
    ???
<frozen importlib._bootstrap>:1360: in _find_and_load
    ???
<frozen importlib._bootstrap>:1331: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:935: in _load_unlocked
    ???
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/assertion/rewrite.py:178: in exec_module
    exec(co, module.__dict__)
tests/test_urdf_exporter.py:1: in <module>
    import idyntree.bindings as idt
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/idyntree/__init__.py:1: in <module>
    from . import swig
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/idyntree/swig.py:10: in <module>
    from . import _iDynTree
E   ImportError: libGL.so.1: cannot open shared object file: No such file or directory

C.C. @traversaro

Probably solved by https://conda-forge.org/docs/maintainer/maintainer_faq/#how-do-i-fix-the-libglso1-import-error

[traversaro]

Since the workaround does not work in the meta.yaml, I believe we can stick to libsdformat13.
For what regards the tests, I'm getting an error on libGL when importing idyntree:

ImportError while importing test module '$SRC_DIR/tests/test_urdf_exporter.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/python.py:487: in importtestmodule
    mod = import_path(
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/pathlib.py:591: in import_path
    importlib.import_module(module_name)
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/importlib/__init__.py:90: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1387: in _gcd_import
    ???
<frozen importlib._bootstrap>:1360: in _find_and_load
    ???
<frozen importlib._bootstrap>:1331: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:935: in _load_unlocked
    ???
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/_pytest/assertion/rewrite.py:178: in exec_module
    exec(co, module.__dict__)
tests/test_urdf_exporter.py:1: in <module>
    import idyntree.bindings as idt
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/idyntree/__init__.py:1: in <module>
    from . import swig
../_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/lib/python3.12/site-packages/idyntree/swig.py:10: in <module>
    from . import _iDynTree
E   ImportError: libGL.so.1: cannot open shared object file: No such file or directory

C.C. @traversaro

Probably solved by https://conda-forge.org/docs/maintainer/maintainer_faq/#how-do-i-fix-the-libglso1-import-error

Yes, you also need to re-render probably.

[flferretti]

@conda-forge-admin, please rerender

[flferretti]

It didn't work, I'm checking again to see if I'm missing something

[diegoferigo]

Probably some other packages are missing, check:

https://github.com/conda-forge/idyntree-feedstock/blob/main/recipe/yum_requirements.txt

[flferretti]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/rod-feedstock/actions/runs/9157803404.

[flferretti]

Probably some other packages are missing, check:

https://github.com/conda-forge/idyntree-feedstock/blob/main/recipe/yum_requirements.txt

Thanks Diego! Yet for some reason it looks like it still doesn't work

[diegoferigo]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/rod-feedstock/actions/runs/9158205457.

[diegoferigo]

@conda-forge-admin, please rerender

[flferretti]

I just noticed the extension, sorry

[diegoferigo]

No problem, LGTM as soon as CI turns green

[diegoferigo]

I have no idea why gitpython required by robot_descriptions does not have git as run requirements:

https://github.com/conda-forge/gitpython-feedstock/blob/7eafcb6a08ecfc216fbd0bd4319a88b66d2901db/recipe/meta.yaml#L21-L24

[flferretti]

See beeware/beeware#32 (comment), conda-forge/staged-recipes#19349 (comment)