Closed bhung-bdai closed 6 months ago
The dependency here is not on all of Gazebo, but rather just the gz-math
and gz-cmake
libraries to provide some basic utility functions. You do not need to install all of gazebo in order to use the sdformat library.
The dependency here is not on all of Gazebo, but rather just the
gz-math
andgz-cmake
libraries to provide some basic utility functions. You do not need to install all of gazebo in order to use the sdformat library.
I agree; we split gazebo into separate libraries in order to be able to reuse code. I'm going to close this since we are not planning to remove the dependency on gz-math at this time, but people are welcome to continue commenting here to discuss this further or request a change
Desired behavior
Separating the SDFormat library from Gazebo, so Gazebo isn't a direct dependency of SDFormat.
Alternatives considered
Alternative SDFormat library from a different vendor which doesn't require a dependency on Gazebo.
Implementation suggestion
I'm not sure what the backend is and if that requires this system to depend on Gazebo, so I won't comment on this.
Additional context
SDF is a format that is ingested by different physics simulation systems (PyBullet, Gazebo, Drake). It's a very useful format and alternative to URDFs for its ability to hardware features such as joint dynamics. It would be nice to programmatically create SDFs without requiring an implied dependence on Gazebo, as many different simulators can ingest them. The Python library appears to depend on the
gz
module. I don't see a particular reason for why this is necessary. Is it possible to separate these libraries? If not, is there an alternative which acts similarly to SDFormat which doesn't have a dependency on Gazebo? The dependency pinning ongz
is also a bit concerning for users stuck on different versions ofgz
.