search

robotology / gym-ignition-models

Collection of robot models compatible with gym-ignition
https://github.com/robotology/gym-ignition
GNU Lesser General Public License v3.0
24 stars 8 forks source link

Reduce the number of environment variables #18

Closed diegoferigo closed 4 years ago

diegoferigo commented 4 years ago

Even if at the time of writing https://github.com/ignitionrobotics/ign-gazebo/pull/172 has not been merged, we should keep an eye on it since it could allow us to reduce the number of environment variables to export.

traversaro commented 4 years ago

I never opened a issue upstream to propose that, but I personally think that it would be ideal to have a single IGN_PREFIX_PATH env variable, similary to how CMake have a single CMAKE_PREFIX_PATH variable even if it also have CMAKE_PROGRAM_PATH, CMAKE_LIBRARY_PATH, etc etc.

diegoferigo commented 4 years ago

Do you mean a single unified env variable that could be used for everything (worlds, models, meshes, plugins, physics plugins, rendering plugins, etc)? In https://github.com/ignitionrobotics/ign-gazebo/pull/172 it seems that they are unifying at least all the SDF resources under IGN_GAZEBO_RESOURCE_PATH, that is already a step forward.

traversaro commented 4 years ago

Do you mean a single unified env variable that could be used for everything (worlds, models, meshes, plugins, physics plugins, rendering plugins, etc)?

Yes.

In ignitionrobotics/ign-gazebo#172 it seems that they are unifying at least all the SDF resources under IGN_GAZEBO_RESOURCE_PATH, that is already a step forward.

Definitely a step forward.

chapulina commented 4 years ago

I never opened a issue upstream to propose that

Just an extra reference, you've brought this up on this other PR :wink:. One of the reasons for keeping some paths separate is for cases when we want to list the entire content of some paths, like how all plugins in IGN_GUI_PLUGIN_PATH end up on the menu. But we're trying to condense them as much as possible.

traversaro commented 4 years ago

I never opened a issue upstream to propose that

Just an extra reference, you've brought this up on this other PR 😉.

Thanks, I had completely forgot about it.

One of the reasons for keeping some paths separate is for cases when we want to list the entire content of some paths, like how all plugins in IGN_GUI_PLUGIN_PATH end up on the menu. But we're trying to condense them as much as possible.

Yes, but to clarify the proposal (at least on CMake) the unified variable CMAKE_PREFIX_PATH exists and is defined as:

Semicolon-separated list of directories specifying installation prefixes to be searched by the find_package(), find_program(), find_library(), find_file(), and find_path() commands. But then there are also individual env variables for each call, if users need more granularity:

Then clearly there is the usual trade-off between flexibility and simplicity, so in any case it is debatable if the unified env variable would be worth it.