search

gazebosim / sdformat

Simulation Description Format (SDFormat) parser and description files.
http://sdformat.org
Apache License 2.0
169 stars 97 forks source link

Ruby dependencies may be undesirable? #274

Open EricCousineau-TRI opened 4 years ago

EricCousineau-TRI commented 4 years ago

Filing this issue based on: https://github.com/RobotLocomotion/drake/issues/13231 https://github.com/ros/urdfdom_headers/issues/59#issuecomment-626147511

I'm not proposing any action yet, but rather to gather use cases where Ruby is high-overhead. Ultimately, this may get closed out as not fixable, but good to have the convo here anywho.

(I assume there are complaints on ROS Answers + Gazebo Community as well; at some point, it would be nice to skim and collect those.)

EricCousineau-TRI commented 4 years ago

From https://github.com/ros/urdfdom_headers/issues/59#issuecomment-626147511:

[...] but unfortunately it depends on Ruby [...]

@traversaro Just to check, what would a more ideal dependency be? Pure C++, Python, a more lightweight Ruby implementation, ...?

From prior conversations, I believe most Ignition tools use Ruby: https://github.com/RobotLocomotion/drake/issues/13231#issuecomment-624160257 https://osrf-migration.github.io/sdformat-gh-pages/#!/osrf/sdformat/pull-requests/434/page/1#comment-65236228

traversaro commented 4 years ago

[...] but unfortunately it depends on Ruby [...]

@traversaro Just to check, what would a more ideal dependency be? Pure C++, Python, a more lightweight Ruby implementation, ...?

Both C++ or Python would be much more convenient from the point of view of macOS/Windows use. Having a dependency on Ruby is relatively fine as long you just use as an interpreter for processing files. If instead you want to load in a Ruby script a plugin written in C++ you will have problems if your plugin has been compiled with a C++ toolchain different from the one with which the Ruby interpreter has been compiled. You can find a few related discussions in:

In theory you could have the same problem in Python as well, but in practice (at least on Windows) the official Python Windows interpreter uses the same C++ ABI of Visual Studio, that is the compiler used by most projects, and even if you want to use MinGW, getting or compiling a Python interpreter for MinGW is relatively easy.

EricCousineau-TRI commented 4 years ago

Gotcha, thanks for the explanation! And just to make sure I understand this workflow:

If instead you want to load in a Ruby script a plugin written in C++ [...]

Is this most directly addressed by https://github.com/ignitionrobotics/ign-tools/issues/7, where ign is the Ruby script that you mention which loads subcommands as shared library functions (rather than doing separate binaries like git, rosrun, etc. do for some of their more complex subcommands)?

traversaro commented 4 years ago

If instead you want to load in a Ruby script a plugin written in C++ [...]

Is this most directly addressed by ignitionrobotics/ign-tools#7, where ign is the Ruby script that you mention which loads subcommands as shared library functions (rather than doing separate binaries like git, rosrun, etc. do for some of their more complex subcommands)?

That is correct.

traversaro commented 4 years ago

Another example in which the Ruby (build) dependency is cumbersome: https://github.com/conda-forge/libsdformat-feedstock/issues/9 . TL;DR: conda-forge removed ruby from their CI machine, and now the only "clean" way forward is to add a ruby port on conda-forge that builds on Windows.