I’m getting so many errors for ‘missing import’ but actually they are not the case. Is there any way I can solve this or tell Pyright not to give this error?
I’m using:
- LSP
- LPS-pyright
- LSP-file-watcher-chokidar
Pyright wrong diagnosis
OdatNurd
#2
I don’t use Django, but from looking at the code, is it not angry that there is a symbol named django that does not exist anywhere because it hasn’t been imported?
If that’s some kind of magic symbol I would imagine that LSP would have to be told that this is a Django related thing so that it knows about an implicit import or something.
0 Likes
KarChung
#3
Hi, thanks for responding! I’m not sure how it work behind the scene.
But this is working on VS Code when I select the interpreter and activate it ( virtual environment )
Then these errors gone. Any clue?
0 Likes
deathaxe
#4
LSP-pyright supports a rich set of strategies to find virtual environments using various popular tools, if they are found on $PATH.
So basically it should find and use all virtual environments, which can also be identified by tools like poetry, pyenv, etc.
It also looks for local .venv or venv directories as well as checking CONDA_PREFIX or VIRTUAL_ENV environment variables. Note, environment varialbes are picked up by ST only at startup. So any venv activated in a possibly local/dedicated terminal after ST was started, is not recognized.
A plugin could however somehow dynmically set one of those environment variables via import os; os.environ["VIRTUAL_ENV"]="/path/to/venv/".
0 Likes
KarChung
#5
Hi, thanks for helping!
So any venv activated in a possibly local/dedicated terminal after ST was started, is not recognized.
In this case, what is the correct way of activating the virtual environment so that ST can recognize it?
I’ve tried to activate the virtual enviroment in the windows terminal first then only start ST, but still nto working.
0 Likes
deathaxe
#6
On Windows, when opening a terminal and activating a venv, set VIRTUAL_ENV variable is local and thus visible/valid only for applications started by this session.
So after activating the virtual environment, ST must be started from within that terminal session by calling subl .. Just starting ST from start menu or desktop link doesn’t work as it wouldn’t run within your terminal session then.
Note: Running subl . requires ST’s installation directory to be registered on PATH.
That’s cumbersome when working in multiple envs in several windows at the same time.
I can’t say anything about the “correct” way, but I just got used to create local environments named .venv in each of my projects, so each one uses its private environment which is identified by pyright out-of-the box by just opening related python files.
- project root
- .git/
- .venv/
- .src/
- .gitignore
- README.md
- pyprojects.toml
I could also imagine to create something like https://packagecontrol.io/packages/Virtualenv, which lists available or configured environments and directly sets os.environ variable, so any python invokation would automatically run within activeted environment.
0 Likes
KarChung
#7
- Do you mean adding the installed directory or the .exe to the registered PATH?
- The .venv folder should be at the same level of the project root directory? However, even I create the venv as the directory you have mentioned:
- py -m venv .venv
- .venv/Scripts/activate.ps1
- Start ST
Still seeing the errors
0 Likes
deathaxe
#8
Do you mean adding the installed directory or the .exe to the registered PATH?
The PATH environment variable is a list of directories in which a shell interpreter looks up executables, so that you can call myexe from command line regardless your current working directory. Any executable located in a directory not being part of (aka. listed in) PATH will only be available by typing its absolute path.
The .venv folder should be at the same level of the project root directory?
Yes. If a local .venv is available you no longer need to open ST and the folder via terminal. This is what makes it easier to handle, because you can just open the folder in ST via explorer.
You most likely still see the error as you didn’t install any packages into that environment.
Running pip install django within your activated virtual environment should fix the issue.
Example using httpx lib.
0 Likes