This is more or less similar to what we were doing long time ago with pybullet (#110, #149).
In few words, after #346 the pure-Python gym-ignition package will depend on scenario. When gym-ignition gets installed in a system (currently only Ubuntu is supported), the wheel of scenario will be installed first. Since the wheel of scenario is not self-contained (i.e. it needs to find in the system the Ignition libraries), if Ignition is not installed, the import of scenario.bindings.gazebo will fail. Therefore, in such systems, gym-ignition cannot be imported.
This seems quite logical, however there are use cases in which resources that are currently included in gym-ignition could be useful even if Ignition is not available in the system. For instance, all the high-level iDynTree classes.
Importing lazily all the scenario.bindings.core is quite easy to do, and I think we should try to support this use case.
This is more or less similar to what we were doing long time ago with pybullet (#110, #149).
In few words, after #346 the pure-Python
gym-ignition
package will depend onscenario
. Whengym-ignition
gets installed in a system (currently only Ubuntu is supported), the wheel ofscenario
will be installed first. Since the wheel ofscenario
is not self-contained (i.e. it needs to find in the system the Ignition libraries), if Ignition is not installed, the import ofscenario.bindings.gazebo
will fail. Therefore, in such systems,gym-ignition
cannot be imported.This seems quite logical, however there are use cases in which resources that are currently included in
gym-ignition
could be useful even if Ignition is not available in the system. For instance, all the high-level iDynTree classes.Importing lazily all the
scenario.bindings.core
is quite easy to do, and I think we should try to support this use case.cc @GiulioRomualdi @paolo-viceconte @traversaro