Shows errors when opening external files not related to project

[bfelbo]

Describe the bug
I often use VS Code's "Go to Definition" functionality to see the underlying code of external libraries, including the standard library. Whenever I open a file pyright will type check the file and find all sorts of issues. I'd very much like to avoid getting a bunch of extra errors when looking up external files and definitions. We use conda so I've added the conda directory containing all the standard/external libraries to ignore in pyrightconfig.json, but the typing checking still happens:

    "ignore": [
        "/usr/local/anaconda3/*"
    ]

It seems that pyright always check types for the open file regardless of the pyrightconfig.json in the current project directory. Is that right? If so, could you add an option to turn off type checking of the open file?

To Reproduce
Use "Go to Definition" on import os in VS Code.

Expected behavior
No type checking when opening external libraries, in particular if they're in the ignore part of the current pyrightconfig.json.

VS Code extension or command-line
VS Code Extension 1.1.30

[erictraut]

This is very much by design. The errors reported in files outside of the workspace are analyzed using default (conservative) settings. These errors appear only while the files are open and are cleared once you close them.

[bfelbo]

Okay. Would it be possible to add a setting to turn this off?

While coding it's common to have the 3rd party code as a reference in split view or another pane. When their errors flood the problems section in VS Code (os in the standard library has ~400 errors), it's very easy to miss an issue in your own code.

[bfelbo]

Or if you prefer not to add a new setting, you could make open files respect the ignore settings?

[jakebailey]

I'd also recommend not showing diagnostics for files not inside the workspace; it's usually not code the user can affect so the errors aren't actionable.

[erictraut]

I expect my editor to show me errors for any code file I open. I don't care so much about whether they're actionable; I still want to know about potential problems.

It may make sense to lower the threshold for errors in this case — e.g. limit it to syntax errors.

I think it's reasonable to support the "ignore" technique. It should already work, so there must be a bug there. I can look into that. However, this technique won't work for projects that involve more than one developer because it involves adding an absolute path to the pyrightconfig.json — a path that will be different on every developer's machine.

[bfelbo]

It sounds great that you'll look into the bug, thanks!

Yes, it's not an ideal solution to add the path to ignore. We're a small team with everyone on Mac using conda so it's not a big problem for us, but I definitely see what you mean.

[erictraut]

I looked into the reason why the ignore wasn't being honored. The issue is that the config file applies only to files that are within the workspace. Pyright uses a generic (default) configuration for files outside the workspace. That means all of the default settings are used in this case.

[erictraut]

I've added a new setting for the VS Code extension called "pyright.typeCheckingMode". It controls the default type checking rules that are used. You can specify one of three values: "off", "basic", and "strict". By default, pyright uses "basic" type checking rules for all python files.

You can override the VS Code setting in the pyrightconfig.json file if you want. It now supports a new config key called "typeCheckingMode", and it accepts one of the three values above.

To get the behavior you want, you'll need to set the VS Code setting to "off" and then set the config file key to "basic".

This support will be in the next published version of pyright.

[bfelbo]

Perfect, thanks!

[erictraut]

This is implemented in 1.1.31, which I just published.

[bfelbo]

I just set this up with "typeCheckingMode": "off" for my VS Code and"typeCheckingMode": "basic" in my workspace pyrightconfig.json. However, when I open os.py (standard library), I still get ~400 pyright issues in my VS Code problems tab.

This is the only output from pyright. What am I doing wrong?

Pyright language server starting
Server root directory: /Users/bfelbo/.vscode/extensions/ms-pyright.pyright-1.1.31
Starting service instance "aura"
Received updated settings
Loading configuration file at /Users/bfelbo/code/aura/pyrightconfig.json
Ignoring path "/usr/local/anaconda3/**" in "ignore" array because it is not relative.
Setting pythonPath for service "aura": "/usr/local/anaconda3/envs/aura/bin/python"
Searching for source files
Found 11 source files

[erictraut]

I just tried your example, and it's working fine for me. When I open "os.py" with typeCheckingMode set to "basic", I receive 52 errors. When I switch it to "off", I receive only two errors (both of them say 'No parameter named "dir_fd"', which is not considered a "type checking" diagnostic).

By any chance, is the "os.py" file within your workspace?

[bfelbo]

Thanks for looking into this. No, there's no os.py file in our workspace.

[erictraut]

Are you loading os.py from a venv that's under your workspace root directory? Or is it coming from a path outside of your workspace's root?

[bfelbo]

It's a path outside the workspace root. It's installed using conda. You can see the path in my original post :)

[erictraut]

I'm at a bit of a loss on this one. I'm not able to repro the problem on my system, so there must be something different. Could you do me a favor and try to repro it with a minimal project, then file a new bug report with the specific repro steps? Thanks!

[bfelbo]

Strange. I'll try to repro it with a minimal project, likely over the weekend.