Support for using python module search path for importing resource file about red

[KrzysztofJozefowicz]

Thanks for input, we will have closer look into it.
For now, RED uses relative paths around project/workspace,absolute paths if specified or check local test file directory when only filename was given.

[pvshewale]

Thanks. We have multiple reusable resource files kept in single common directory and we import them in test case with only filename. And we set PYTHONPATH to that common directory before running pybot cli. So same test case files will not work as it is in RED.

Is there any workaround like setting is red.xml file? Can we set additional search path in red.xml?

[KrzysztofJozefowicz]

We had a fruitful discussion about searching resources files in PythonPath.
We decided that we will not support such scenario because various reasons.
Robot provides flexibility in many areas ( like above or keyword naming for instance) which are handy but on the other hand can cause problems. In our opinion PythonPath should only be used for Python specific elements (like libraries) and not for Robot framework artifacts.
We see such usage as anti pattern which should be avoided if possible :

1. by placing common resources in PythonPath, you mix test material with environment setup. It can lead to problems with transfer tests between different testbeds ( you may not have proper access rights to modify PythonPath )
2. resource file name collision can happen but it will be hidden. Which resource will be returned to Robot if there are multiple files with the same name in PythonPath? I have not tested this but risk is that depending on OS and timing results may vary (difficult to debug)
3. system performance could be affected while editing and testrun as Robot needed to search dir tree for files instead of using explicit paths
4. test maintenance is easier when each test suite provide path to used resources
5. debugging in RED could be tricky as we would have to jump to files outside workspace when executing Step In option.

I suppose you already have your test cases and common resources in some kind of version control so common resources should be somewhere in the directory tree adjacent to test files.

One way is to use linking resource files/folders to RED project (New -> File -> Advanced -> Link to file .. and Import -> General -> File System -> Advanced ...) in the same folder as test suite files. This way example.robot will be seen by RED. If there are problems with test execute or test debug you can have a look into Run Configurations if any arguments needs to be passed to Python

Other way (my recommendation) is to spend a little time and do mass search & replace/update of resource usage in test suites. You can use Robot ${EXECDIR} (path where output.xml and report.html is generated, this is also Project path in RED) variable to create common path to resources so in any depth of test suites dir tree, same path to resource can be used.
Additionally (for RED v0.5) current path to RED project have to be mapped in variable mappings (in 0.6.x we will handle it statically per project ). This way your tests will be environment independent and easier to maintain with less prone to hidden problems.

[pvshewale]

Thanks a lot for detailed reply. At present it solved my problem with your suggestion of linking resource file.

[ed-karabinus]

I am having the same issue initially described by @pvshewale.

Created resource file example.robot inside E:\test
Added E:\test to system environnment variable PYTHONPATH
Opened RED and tried to import above resource file as
Resource example.robot
RED fails to import resource file and gives error like "file does not exist"

I do not understand how to implement the fix offered by @KrzysztofJozefowicz. Could either of you explain in more depth? Ultimately, this behavior works very well in RIDE (add a library containing Robot resources to "Ride - Preferences" -> Importing -> PYTHONPATH, like E:\test as above, then the import using a relative path [e.g., "Resource example.robot"] works perfectly). I understand what @KrzysztofJozefowicz was saying about this being an anti-pattern, but I have little choice as my organization heavily relies on this relative import path functionality.