Ruby dependencies may be undesirable?

[EricCousineau-TRI]

Filing this issue based on:
RobotLocomotion/drake#13231
ros/urdfdom_headers#59 (comment)

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]

From ros/urdfdom_headers#59 (comment):

[...] 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:
RobotLocomotion/drake#13231 (comment)
https://osrf-migration.github.io/sdformat-gh-pages/#!/osrf/sdformat/pull-requests/434/page/1#comment-65236228

[traversaro]

[...] 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:

• Apple support for ign command line tool gz-sim#25
• Consider binaries to implement the functionality offered by gz gz-tools#7
• Ign gazebo render window does not work in same process as server on macOS gz-sim#44

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]

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 gazebosim/gz-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)?

[traversaro]

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]

Another example in which the Ruby (build) dependency is cumbersome: conda-forge/libsdformat-feedstock#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.