[ros2] Extend plugin path instead of overwriting it in ign_gazebo launch script

[AndrejOrsula]

IGN_GAZEBO_SYSTEM_PLUGIN_PATH is currently being overwritten by LD_LIBRARY_PATH when using ign_gazebo.launch.py. I am failing to find a mention of LD_LIBRARY_PATH with respect to plugins in Finding resources, so I am not sure if it is meant to be an alternative.

Unless I am missing something, I believe that IGN_GAZEBO_SYSTEM_PLUGIN_PATH should be treated the same way in both of these cases for worlds with custom plugins.

• ign gazebo example.sdf
• ros2 launch ros_ign_gazebo ign_gazebo.launch.py ign_args:="example.sdf"

To keep this change backwards compatible for people who export LD_LIBRARY_PATH to find custom plugins, I suggest extending IGN_GAZEBO_SYSTEM_PLUGIN_PATH with LD_LIBRARY_PATH instead of overwriting it.

[chapulina]

Nice catch! I agree that we shouldn't overwrite the variable.

I am failing to find a mention of LD_LIBRARY_PATH with respect to plugins in Finding resources

Good point, I think it could be mentioned. LD_LIBRARY_PATH is a Linux variable and tools like colcon set it. In general, Ignition libraries try to respect LD_LIBRARY_PATH on Linux and DYLD_LIBRARY_PATH on macOS.

[AndrejOrsula]

In general, Ignition libraries try to respect LD_LIBRARY_PATH on Linux

That's great.

LD_LIBRARY_PATH is still not searched automatically when loading plugins using ign gazebo example.sdf though. I assume that's by design and using a separate environment variable is a common practice for locating shared objects in plugin-based architectures?

[chapulina]

LD_LIBRARY_PATH is still not searched automatically when loading plugins using ign gazebo example.sdf though.

Interesting, I assumed it would work, but it doesn't. The only drawback I can see is if the user has some Gazebo classic plugin installed in LD_LIBRARY_PATH with the same name as an Ignition plugin, and the simulator tries to load the wrong one by mistake.

using a separate environment variable is a common practice for locating shared objects in plugin-based architectures?

That's certainly something we've been doing on Ignition, but there are projects that locate plugins in other ways. For example, enforcing that all plugins be installed to a given directory.