[BUG] Glob pattern in python-path setting (robot.toml) does not work

[bennyvw]

Describe the bug
In robot.toml the setting python-path can be used. According to the specs (https://robotcode.io/03_reference/config#python-path) a glob pattern can be used.
When I try this:
python-path = [ "Resources/Actions" ]
it works for the keywords in that folder. But when I try this:
python-path = [ "Resources/**" ]
(which should be correct according to https://globster.xyz/) it does not work. The imports in my robot files show up as 'not found'.

Steps To Reproduce

1. Make sure Resources folder exists with subfolder containing keyword libraries.
2. Create robot.toml with this line:
   python-path = [ "Resources/**" ]
3. Have a .robot file importing a resource from the subfolder in Resources.

Expected behaviour
The resource can be found.

Actual behaviour
The resource cannot be found.

Desktop (please complete the following information):

• VS Code Version 1.95.2
• 0.96.0 RobotCode Version
• 7.0.1 Robot Framework Version
• 3.11.8 64-bit Python Version
• 5.4.0 Robocop Version
• 4.14.0 Tidy Version

[d-biehl]

is it working when you give to glob pattern directly to robot, without using robot.toml?

[bennyvw]

Yes, I tried this command and that works fine:
robot --pythonpath Resources/** .\Tests\API\contract-info-api\Contract_items.robot

[d-biehl]

ok, found it, should work in the next version

[bennyvw]

I just updated RobotCode to 0.97.0, but the solution does not work for me. When I change the python-path in robot.toml into python-path = [ "Resources/**" ], the imports in my .robot file turn red.
It is possible to Ctrl-Click the resource files and open them, but the keywords cannot be found and when running a testcase it errors out.

[d-biehl]

Could you perhaps provide a more detailed example of your project structure and show how the imports are set up? It would be helpful to understand if there are any identically named files in subfolders that might be causing the wrong resource file to be imported.

Additionally, could you share the exact error messages? Is the issue occurring directly at the Resource statement, or is it only that the keywords from the resource file aren’t being found?

[bennyvw]

This is the structure of my project:

This is the error message at resource import:

This is the error message at keyword calls:

And yes, there are some files with the same names in different subfolders, like ENV.py.

[d-biehl]

where is the Engine_shared.resource file located? I can't see it in the screenshot

[bennyvw]

where is the Engine_shared.resource file located? I can't see it in the screenshot

It is in Implementation/Web

[d-biehl]

Ok, I think the issue is that Robot Framework doesn’t apply the glob pattern recursively but only directly to the directory you specified beforehand.

Could you try loading the resource with the Web folder like this?

*** Settings ***
Resource  Web/Engine_shared.resource

What exactly do you want to achieve by using glob patterns?

[bennyvw]

Preceding it with 'Web/' proves that only the first level of subfolders is parsed, then the resource can be found! Which is not correct, according to the glob pattern specs.

The reason I tried to use glob patterns is that this:
python-path = [ "Resources/**" ]
is shorter and easier to maintain than this:

python-path = [ "Resources/Actions",
                "Resources/Implementation/JSON",
                "Resources/Implementation/ContractData",
                "Resources/Implementation/Database",
                "Resources/Implementation/Web",
                "Resources/Implementation/XML",
                "Resources/Libraries",
                "Resources/Scenarios" ]

And it's more future proof when new subfolders may be added.

[d-biehl]

Ok, but RobotCode implements this exactly as it’s done in Robot Framework. If you’d like to see this behavior changed, you might consider opening an issue with Robot Framework or asking about it there.

However, I think it might be worth reconsidering your strategy. At first glance, it might seem easier this way, but you risk losing track of where resources are coming from within a single file. Are they technical resources, business logic, helper keywords, or something else.. and you may run into issues if you have resources with the same name, among other potential challenges.

In other programming languages, namespaces and package/module systems were introduced precisely to address these kinds of issues. And you've already set up a well-structured project—take advantage of that! Code is more than just code; it’s also documentation, as someone once told me. ;-)

[d-biehl]

Here are a few additional thoughts from me:

I believe that adding the Resources directory to the Python path and importing specific resources with the format namespace/folder/keywords.resource can promote a cleaner, more organized setup. This approach aligns with essential software design principles like Separation of Concerns and the Single Responsibility Principle, commonly implemented in other programming languages through packages, namespaces, and modules.

In many languages, packages and namespaces help organize code into logical groups, prevent naming conflicts, and make specific functionality easier to locate and reuse. For instance, distinct modules might manage database interactions, business logic, or utility functions, making it simpler to maintain and enhance specific parts of a project independently. This structure also enables team collaboration by allowing parallel work without conflicts.

Although Robot Framework doesn’t use formal namespaces, a structured folder and naming approach can achieve similar benefits. For example, keeping helper keywords in a dedicated Utilities folder, business logic in an Actions folder, and technical implementations in an Implementation folder establishes clear boundaries, reducing confusion and improving readability. In this way, your project structure serves not only as code but also as documentation, making it easier to understand, extend, and maintain.

[bennyvw]

Thanks for your thoughts! This is valuable feedback. I am going to rethink the strategy.
Wanted to get rid of the ../../../ in imports (it is a project set up by someone else), but using the pythonpath to rigourously we are going to lose some information indeed.