Reputation: 93
I am working on a python package with VS Code with the following layout of the opened workspace folder in VS Code
workspace
| + tests
| | - test1.py
| | + other_tests
| | | - test2.py
| + mymodule
| | ...
What I want is to call in test1.py
and test2.py
the package mymodule
with
import mymodule
When I do this, I always get the error no module named 'mymodule'
. I know i can load the path via inserting the following to all test files:
import sys
sys.path.append('<path_to>/workspace/')
Then mymodule
is correctly loaded. (I know I can use pathlib.Path(__file__).parent[n]
for some n
to get <path_to>
.
But this process is really cumbersome if you have many test files in different folders... and it is just ugly.
Is there any way, to tell VS Code to always include the workspace
in the path?
I tried a .env
file with
PYTHONPATH=<path_to>/workspace/
and I also tried to add the following to launch.json
:
"env": { "PYTHONPATH": "${workspaceFolder}" }
Both did not do the trick. (I am also not sure if PYTHONPATH
is at all the right solution to my problem, i just tried it ^^).
I would like to tell VS Code, that it should always include workspace
to the search path whenever a python function tries to load a module, regarding the location of the function, so I do not have to call sys.path.append('<path_to>/workspace/')
in every single main file.
Upvotes: 7
Views: 15636
Reputation: 9883
When the python interpreter is importing a package, it looks for the package in the following locations:
the directory containing the input script (or the current directory).
PYTHONPATH (a list of directory names, with the same syntax as the shell variable PATH).
the installation-dependent default.
So if your package and script file are in the same directory, it will be easily found. But obviously you chose a different directory. Then you have to use the methods mentioned in your article to specify the path to the interpreter, such as modifying the PYTHONPATH environment variable or using the sys.path.append()
method.
Here's a suggestion for another approach. Put your package where python can find it, say under the lib
folder. This way you don't need to use the sys.path.append()
method at the beginning of each file.
I am using a virtual environment
UPDATE:
You can use virtual environments. it won't make a difference. If you are worried about some factors and do not want to use it, there is no problem. Just find the lib
folder in your current environment and put your package in it.
for example ( As far as my machine is concerned ) :
The lib
folder corresponding to the interpreter of this environment is in:
C:\Users\Admin\AppData\Local\Programs\Python\Python310\Lib
The lib
folder corresponding to the interpreter of this environment is in:
C:\Users\Admin\anaconda3\Lib
PS : It can also be placed in the site-packages
folder one level below the lib
folder.
Upvotes: 3
Reputation: 8511
Option #1 (Recommended): Split into a separate package
Since what you are basically looking for is to have mypackage
as a full-blown package accessible to all the code in this environment, why not do that?
Just separate mypackage
into a separate pip package, and then "install" it using pip
into a virtual environment that you are using within this project.
Option #2: Use PYTHONPATH
From Python's manual:
PYTHONPATH: Augment the default search path for module files. The format is the same as the shell’s PATH: one or more directory pathnames separated by os.pathsep (e.g. colons on Unix or semicolons on Windows). Non-existent directories are silently ignored.
Visual Studio Code definitely supports setting PYTHONPATH
through .env
:
The PYTHONPATH environment variable specifies additional locations where the Python interpreter should look for modules. In VS Code, PYTHONPATH can be set through the terminal settings (terminal.integrated.env.*) and/or within an .env file.
However, you have to be careful about the following note (same page, two paragraphs below):
When PYTHONPATH is set using an .env file, it will affect anything the extension does on your behalf and actions performed by the debugger, but it will not affect tools run in the terminal.
So, if you are trying to run your project from the terminal directly, this will not work.
Upvotes: 1