Mixing default and custom paths

[chapulina]

Environment

• OS Version: Ubuntu, all
• Source or binary build? ign-tools from binaries, some downstream libraries from source

Description

Expected behavior:

Ignition Tools looks for yaml configuration files in a few different paths:

• A path relative to where ign-tools was installed
• Paths in the IGN_CONFIG_PATH environment variable

The first supports libraries installed the same way as ign-tools. For example, if ign-tools was installed from debs, then it will find other Ignition libraries also installed from debs. While the latter is convenient when installing libraries to custom locations, for example when installing from source for development.

Currently, the user has to choose one or the other. It would be nice to have a way to easily combine both.

Actual behavior:

If IGN_CONFIG_PATH is set, then the install path is ignored.

Steps to reproduce

1. Install ignition-tools and libignition-transport<n> from debs
2. Compile ign-msgs from source
3. Running ign msgs --help, you'll still be seeing the one from debs
4. Set export IGN_CONFIG_PATH=path_to_ign-msgs_source_install
5. Running ign msgs --help, you'll see the one from source, but running ign won't show ign-transport's commands

Additional context

Here's where the path logic is:

https://github.com/ignitionrobotics/ign-tools/blob/83d5de7e33da239f714245e53d91b05651601034/src/ign.in#L35-L37

As you can see, if IGN_CONFIG_PATH is set, it overrides the other.

Also note how various Ignition libraries have a disclaimer on their READMEs because of this issue, i.e.

https://github.com/ignitionrobotics/ign-msgs/#known-issue-of-command-line-tools

Suggested solution

I suggest that instead of IGN_CONFIG_PATH overriding the default install path, we prepend the install path with paths from the environment variable. This way, the user can override a deb install for one library, like on the example above, but still use all other libraries from debs. The downside is that there's no way to completely prevent debs from being used, but I'm not sure if there's a valid use case for that.