yarp
yarp copied to clipboard
robotology
Alternative way of setting YARP_ROBOT_NAME in ResourceFinder
In some use cases it may be convenient to avoid specifying the YARP_ROBOT_NAME through an environmental variable, but it may be preferable to specify it in the code. The use cases involve testing or data analysis, in which you want to make sure that a given analysis script outputs always the same result (as in https://github.com/robotology/mex-wholebodymodel/issues/32). In such a case is better to avoid messing with the environment in the code (because we have no guarantee that the environment would be restored to its original value). We then need to modify the YARP_ROBOT_NAME as seen by the ResourceFinder class through the code.
I see two possible solutions:
C++ API
Add to the ResourceFinder class a setYarpRobotName(const char * yarpRobotName) with the following meaning: if this method is not called, then the resource finder picks as the YARP_ROBOT_NAME the one found in the YARP_ROBOT_NAME environmental variable as always. If instead the method is called, the ResourceFinder ignores the YARP_ROBOT_NAME environmental variable, and use in its place the value set with the method.
Pro:
- Clearly documented meaning, it should not be source of confusion
Con:
- Needs a modification in the source code to be used
Parameter with special meaning
The ResourceFinder has already some parameters (such as context or from) that have a specific meaning. We can add a special parameter (such as yarpRobotName or even YARP_ROBOT_NAME to reduce ambiguity as much as possible) with the following meaning:
if this special parameter is not found at configure time, then the resource finder picks as the YARP_ROBOT_NAME the one found in the YARP_ROBOT_NAME environmental variable as always. If instead the this parameters is found at configure time, the ResourceFinder ignores the YARP_ROBOT_NAME environmental variable, and use in its place the value contained in this parameter. In the latter case, if the special parameter is found but is not a string, the configure fails.
Pro:
- Can be used to modify the behavior of existing module easily
Con:
- Perhaps more error-prone, source of confusion for the users.
cc @francesco-romano @drdanz @lornat75
What is wrong with the obvious solution to add the environment variable from code using the functionalities provided by the os (after proper wrapper by YARP, i.e. in OS.h)?
I was assuming that variable setted by setEnvironment would persist after exiting the program.. but that is not the case (just test). Then I guess we can simply use that, at least for this use case.
Did you use Network::setEnvironment()?
http://wiki.icub.org/yarpdoc/classyarp_1_1os_1_1NetworkBase.html#a1e29e5ea66b4718f928a06299a670e7e
Actually I fear how setting the environmental variable explicitly in the code affects the behavior of the code in scripting languages, such as Python or MATLAB . However I agree that the current solution is good enough, as long as we don't experience any problem.
I was assuming that variable setted by
setEnvironmentwould persist after exiting the program.. but that is not the case (just test). Then I guess we can simply use that, at least for this use case.
Some insights gained from being older: a possible problem of setEnvironment is that it has a process-wide effect, so if you have multiple threads with multiple ResourceFinder instances a setEnvironment in one thread will influence the behaviour of all ResourceFinder instances. The strategies outlined in https://github.com/robotology/yarp/issues/593#issue-108923774 instead do not suffer from this problem.
@traversaro Should we re-open this issue?
Ok for me, or we can wait for someone to have a specific need for this.