Library Module not found error

[shiv (Shiv Matliwala)]

I am making some sub-libraries(each as a module(a directory) with two files:- function file(.py) and init.py file) which I can use into the main library functions which will be used into the keyword file (List_of_keywords.resources). Now inside the python project the directories are as below order,

NewProject
Project1_robot
New_robot.robot
List_of_keywords.resources
New_robot_library.py
MyRobotLibraryNew
init.py
CaptureFunctions.py
Sub-Lib_Module2
init.py
venv
.
.
.

First I am using the Model1_Function file’s functions inside the New_robot_library.py file.

and then

when I am trying to import the New_robot_library.py in List_of_keywords.resources file it is showing that
the ModuleNotFoundError error like below and the color is also not changing like in case of “Library
OperatingSystem” ,

You can see the folder structure here in above picture and the three files as well.

So, do anyone have any idea what should I do here ?

[JaPyR (Aleh Borysiewicz)]

You have to add root of the project (NewProject) to PYTHONPATH. If you are using “Robot Framework Language Server” extension add to settings:

    "robot.pythonpath": [
        "${workspaceFolder}"
    ],

To robot parameters while executing add -P . (assuming that your execution directory is root of the project).

[shiv (Shiv Matliwala)]

I don’t get it. Can you tell me exactly in which file should I write this ?

[shiv (Shiv Matliwala)]

Can you please specify how and where should i write the code which gave me ?

[shiv (Shiv Matliwala)]

Can you please show me with screenshot, how and where should write the code ?

[robinmackaij]

I would suggest making your libraries actual (local) distributions / packages so they get installed in your Python environment (hopefully a virtual environment) like all other dependencies. If you do that, you won’t have to use hacks to make the language servers work correctly and things will work on pipelines / other machines as well. I made a repo to demonstrate this:
GitHub - robinmackaij/robotframework-poetry-demo: A package to demonstrate how poetry can be used to distribute Robot Framework resources within an organization

I also did a talk at RoboCon on the topic:
RoboCon 2022 - 1.08 Project and package management: Poetry for robots - YouTube

[kamichal (Michal)]

@robinmackaij

If you do that, you won’t have to use hacks to make the language servers work correctly

What hacks? Having clear import paths is not a hack. The problem is that “Robot Framework Language Server” ignores PYTHONPATH setting and other environment variables.

Don’t call it a hack. Call it a bug in RF-LS and vscode.

[rasjani (not available)]

Its not a bug nor a hack. Stating it as such feels very poor background knowledge on how environment variables are inherited, how processes are started via editor, and/or how your environment actually works without relying on “magic, it just works”.

[kamichal (Michal)]

Shocking altitude, indeed. I hope you can redirect your frustration into help with solving that, Mr. Rasjani:

Environment variables not used in RF-LS in vscode

Set an environment variable MY_VARIABLE to be used by RF-LS. Then create a robot script: *** Settings *** Library OperatingSystem *** Test Cases *** Show env var Environment Variable Should Be Set MY_VARIABLE Then run it, and it fails, claiming the variable is not set. I set the variable by going to Extensions → Robot Framework Language Server → (small gear icon) → Settings. Then in the search write “Env” and click “Edit in settings.js”. Then add this snippet: "robot.pyt…

[robinmackaij]

Robot Framework Language Server not picking up on environment variables could be a bug, depending on what environment settings it supports on what processes and through which settings. However, that project is now unmaintained, so the odds of the issue being addressed is very low. It’s certainly not a bug in VS Code.

rasjana is right in correcting me on calling use of PYTHONPATH a hack since it is indeed a concept supported by the Python interpreter. His “magic, it just works” is indeed a better description.

But, like magic, “it just works” if you cast the right spell under the right circumstances and if you cast the wrong spell at the right time or the right spell at the wrong time, it either doesn’t work or does something you didn’t expect.

The last part is why I discourage the use of PYTHONPATH except under very specific circumstances (i.e. process-scope injection). The problem with PYTHONPATH additions in the language server to make your project run is that a CI pipeline isn’t using an IDE with a plugin with those settings. So you need to use the -P flag on the pipeline. And then a colleague (perhaps using another IDE and / or language server) can’t run things out of the box since there’s a reliance on setting certain paths in a configuration file for a certain tool.

Making the resources of a Robot Framework repo an installable package prevents all these issues, since the resources will be “just another Python module in the usual place”. If the language server is pointing to the correct Python interpreter (which VS Code does well, Pycharm somewhat less, in my experience) the library / keyword discovery will just work. And no -P will be needed in the pipeline.