Update configuration parsing logic

[xela-95]

Note

This PR affects all plugins

With this PR every plugin can specify its yarp configuration both with <yarpConfigurationString> and <yarpConfigurationFile>.

When using <yarpConfigurationFile> the path to the file can be specified in the following ways:

• URI (preferred): using the scheme[//authority]path[?query][#fragment] (see https://gazebosim.org/api/common/5/classgz_1_1common_1_1URI.html for more info);
• Relative path
• Absolute path: this approach works but is highly discouraged since it does not work on other hosts.

Closes #68
Closes #80

[xela-95]

@traversaro any idea on why the unit test with the CI fails in loading the plugins? I don't know how to debug this, since on my machine it works. Maybe on my machine gazebo finds the plugin libraries in the install directory?

[xela-95]

@traversaro any idea on why the unit test with the CI fails in loading the plugins? I don't know how to debug this, since on my machine it works. Maybe on my machine gazebo finds the plugin libraries in the install directory?

Ok found! This test was missing his GZ_SIM_SYSTEM_PLUGIN_PATH environment variable so it was unable to find plugins.

[xela-95]

Now there is the Windows conda CI failing with:

D:\a\gz-sim-yarp-plugins\gz-sim-yarp-plugins\libraries\common\ConfigurationHelpers.cpp(140): error C2679: binary '=': no operator found which takes a right-hand operand of type 'std::filesystem::path' (or there is no acceptable conversion)

[traversaro]

Relative path

Relative path w.r.t. to what?

By the way, do you think we could document the semantics of yarpConfigurationFile that you wrote down in this PR somewhere in the docs of the repo?

[xela-95]

Relative path w.r.t. to what?

By the way, do you think we could document the semantics of yarpConfigurationFile that you wrote down in this PR somewhere in the docs of the repo?

Sorry for the ambiguity, the path is relative to the current working directory.

For example, looking at the ForceTorqueTest, the robotinterface path is specified as:

gz-sim-yarp-plugins/tests/forcetorque/model.sdf

Line 152 in 9617ad9

<yarpRobotInterfaceConfigurationFile>../../../tests/forcetorque/forcetorque_nws.xml</yarpRobotInterfaceConfigurationFile>

and it is actually resolved to the absolute path /home/acroci/repos/gz-sim-yarp-plugins/build/tests/forcetorque/../../../tests/forcetorque/forcetorque_nws.xml

I'm thinking to update the handling of the relative path by using std::filesystem::canonical or std::filesystem::weakly_canonical (see https://en.cppreference.com/w/cpp/filesystem/canonical) in order to remove ./ and ../ sections and have a "canonical" path.

Yep I will also add a section in the README specifying the alternatives to specify paths.

[traversaro]

I am not sure it is is a great feature, basically it (silently, not in a really clear way) constraints the sdf to be opened only if the simulator or the executable using the gz-sim as a library is launched in the directory it is intended to be launched. I guess we need it know for the tests, but probably we can avoid to advertise it/discourage to use it in actual models (a bit like absolute paths).

[traversaro]

See comments.

[xela-95]

I am not sure it is is a great feature, basically it (silently, not in a really clear way) constraints the sdf to be opened only if the simulator or the executable using the gz-sim as a library is launched in the directory it is intended to be launched. I guess we need it know for the tests, but probably we can avoid to advertise it/discourage to use it in actual models (a bit like absolute paths).

After more carefully thinking about it, I agree with you. I mainly added the relative path feature in order to be compatible with the models already present in tests and tutorials that were using relative paths, but this could become tricky and cumbersome to debug for users.

Do you think it's better to remove this feature for now and refactor the paths in test and tutorials to use the URI? Or we should treat relative paths like absolute ones, by logging a warning for a potentially unreliable path while allowing it?

[traversaro]

Do you think it's better to remove this feature for now and refactor the paths in test and tutorials to use the URI? Or we should treat relative paths like absolute ones, by logging a warning for a potentially unreliable path while allowing it?

I would go for the fast option, that I guess it is the second.

[xela-95]

macOS test disabled related issue: #90

[xela-95]

Updated README

[xela-95]

Merging! 🚀