all third party imports not resolved in VS Code

[agustaf]

Greetings,

Thanks for making pyright, I really like it and use it a lot.

I'm having an issue where all third party library imports are flagged as unresolved by pyright in VS Code. I'm using VS Code 1.41.0 with the pyright plugin. I'm on Windows 10 Enterprise Version 1909. The python installation is Anaconda, with Python 3.7.5.

I've tried creating Anaconda virtual environments (conda create ...) and adding the envs directory to the pyright Venv Path global setting. Pyright seems to fail to resolve all third party imports with this configuration, with different environments activated in VS Code. I've also tried creating a pyrightconfig.json file in the base directory of a project, and specifying extraPaths in the root environment to point to the relevant site-packages directory. This also seems to not have an effect. It currently seems to always fail to resolve third party packages for me. Perhaps I am doing something wrong that I am unaware of.

In terms of execution in VS Code, the libraries are actually importing correctly. The VS Code python plugin resolves the imports, and things like mypy seem to lint correctly.

Thanks for your help.

[agustaf]

I've uncovered a little more info on the problem. My usual process of opening a file in VS Code has been: open the file directly, then switch conda virtual environments using the VS Code environment selector. Following this process seems to result in pyright not resolving the third party libraries in the conda virtual environment, although the path to the directory containing the envs was added to the pyright virtualenv path config.

If I open a folder in VS Code (File -> Open Folder) , instead of a file directly, then it appears to resolve the third party imports. Possibly "Open Folder" is necessary to make it use the pyrightconfig.json file?

In any case, I can work around the issue for now. Possibly in the future it might be cool if pyright worked with the VS Code conda environment selector.

[erictraut]

Pyright looks for the pyrightconfig.json file in the root of your workspace (i.e. the folder you open). If you don't open a folder and instead open some random source file, pyright will still attempt to analyze that file, but it will use its default settings plus any settings that come from VS Code.

That said, you shouldn't need a pyrightconfig.json file for the scenario you've described above. When you select the python environment in VS Code, the setting "python.pythonPath" is updated to point to that environment. Pyright is informed any time that setting changes, and it should honor it when resolving imports.

I just downloaded and installed the latest version of anaconda and followed your steps above. I wasn't able to repro the problem you're seeing. Here are the specific steps I followed:

1. Installed anaconda
2. Created a new virtual environment (conda create -n conda37 python=3.7 anaconda)
3. Opened VS Code; Python and Pyright extensions are already installed
4. Created a new file test.py and typed import colorama; Pyright flagged the import as "not resolved"
5. From the python environment picker at the bottom of the VS Code window, I selected "conda37", the virtual environment I created in step 2
6. Pyright automatically reanalyzes the open file, and the error reported in step 4 no longer appears; it's now able to resolve the import as expected

Let me know if I've missed any relevant steps.

[agustaf]

Thanks much for the info. After a little more testing, it looks like the particular case that fails for me is almost the one you describe, but then I close and re-open VS Code, the same file appears open after the restart, and the virtual environment appears to persist in the bottom bar of VS Code, but it won't resolve the imports.

It looks like just after the first virtualenv switch it does resolve the imports, it is after VS Code restarts where the file re-opens and the virtual environment appears to persist that it complains about the imports. I've been making config file changes and restarting VS Code to see if it ingests the config to resolve the imports, but maybe the problem is with the persistence of the virtualenv between VS Code restarts.

[erictraut]

When you select a new environment, VS Code should update the setting "python.pythonPath". You can open the settings UI in VS Code to view the current value. Pyright receives that setting value from VS Code when it starts. It also receives an updated value for that setting whenever it changes.

[erictraut]

Another potential clue... When Pyright starts, it logs the value of "python.pythonPath" that it receives from VS Code. You can view this log by opening the Output panel (View -> Output) and selecting Pyright from the menu. You should see something like:

Setting pythonPath for service "XYZ": "<path to your conda env>"

[agustaf]

Thanks for the info. I just tried it again, and here is what seems to be happening for me.

1. Open a file in VS Code (File -> Open File)
2. Select an anaconda virtualenv from the bottom bar (this makes the imports resolve)
3. Close and re-open VS Code. The file appears open again, and the virtualenv listed in the bottom appears to persist as before, but the imports don't resolve. The pythonPath setting in the UI appears to be:
   C:\Users...\AppData\Local\Continuum\anaconda3\envs\h2o\python.exe
4. After the restart, View -> Output -> Pyright shows this:
   Pyright language server starting
   Fetching settings for workspace(s)
   Received updated settings
   Starting service instance ""
   Searching for source files
   No source files found.

I don't know, maybe there is something peculiar in my setup that prevents pyright from getting the new pythonPath after VS Code restart. I can fix it by de-activating and re-activating the virtualenv after VS Code restart.

[agustaf]

It says "default" between angled brackets after "Starting server instance" in the pyright output. Looks like that was stripped out of the text paste.

[erictraut]

Thanks for the additional steps. I was able to repro the problem and confirm that it's a bug. A fix will be in the next published version of Pyright.

[erictraut]

This is now fixed in version 1.1.12, which I just published.