Diagnostics from ignored/excluded paths are reported

[JeroenBos]

Bug description

Diagnostics are reported for files matching ignore and exclude in pyrightconfig.json.

I'm trying to prevent diagnostics to appear in vscode Problems output in (base) library code. I can't seem to exclude/ignore the io.py file, as you can see in the screenshot below.

To Reproduce

Exclude the base python installation path in the pyrightconfig.json, like in the screenshot.
Open a file from the base python installation in Windows.
Observe the reported diagnostics.

Expected behavior

No diagnostics to show up for the file.

Screenshot of behavior

Things to note in the screenshot:

• The path of the diagnostics reported: C:\Program Files\Python38\lib\io.py
• That file (io.py) is open (as you can see in the top).
• Ignoring/excluding ".\venv" is honored, because if I remove that I get lots more diagnostics.

VS Code extension

I use pyright through the extension Pylance, but I don't think it's Pylance-specific.

• VSCode 1.55.2
• Pylance: 2021.5.1
• Win10: 19042.928

Extra information

I've tried all sorts of combinations of glob patterns/full path, and path separators.
I've paid attention to case-sensitivity of the paths (even though I'm on windows).
I've restarted vscode plenty.
The diagnostics in the screeenshot were reported in all cases.

[erictraut]

The pyrightconfig.json is meant to configure the settings for a specific workspace, and most of the paths within it are assumed to be relative to your workspace root directory. This is true of the "include", "exclude" and "ignore" configuration options. If you open the Output tab and choose "Pyright" (or "Pylance"), you should see an error that says something like:

Ignoring path "C:\\Program Files\\Python38\\lib\\io.py" in "ignore" array because it is not relative.

The other paths you've specified (".\\venv" and "**\\Python38\\**") are assumed to be relative to your workspace.

It looks like you are opening a file outside of your workspace, so the "ignore" setting doesn't apply to it. When you open a file outside of your workspace, pyright will still analyze it and report errors on it.

I'd like to understand your use case a bit better because it sounds like you're using it in a way that I didn't anticipate when I implemented the "ignore" configuration option in pyrightconfig.json.

1. Under what circumstance are you opening source files outside of your workspace?
2. Why do you want to suppress the diagnostics in these files?
3. Are you checking in your pyrightconfig.json file to a code repository? If so, is this repository shared with other developers?

[JeroenBos]

I'm opening source files outside of my workspace for two reasons:
- I am debugging code and stepping into a function leads me to a file that is not in my workspace.
- I am navigating code and e.g. "Go to definition" opens a file that is not in my workspace.
I should note that both of these are accidentally outside of my workspace. For all I know the files I'm navigating to are in my virtual environment. The files are library files of course; not from my own projects.

A more detailed analysis of why this happens is that probably both the execution of code and resolving of symbol definitions make use of PYTHONPATH (which I think mainly inherits values from plain-old PATH, but may also include workspace-dependent paths). Suppose I haven't installed a package in my venv then it automatically resolves to my global python installation. I think that's how I end up in place outside of my workspace.

Don't get me wrong, this may simply be misunderstanding of the tools I'm using, rather than necessarily a problem with pyright. I think I should avoid python from resolving packages from my global python. But of course without breaking the global python, but that requires effort and understanding of how to achieve so, and that it is a problem in the first place. I'm not aware of how to prevent vscode from resolving source files in a particular directory. In runtime it could be resolved with something del sys.path[1:] but that would obviously be a hack. It boils down to this I think: how to limit the LSP (and runtime) to the virtual environment only?

I want to suppress the diagnostics of these files because they show up in vscode and they are noise. Since they are not diagnosing my code, I'm not interested in the diagnostics; they're intended for somebody who could fix them, i.e. library authors. The diagnostics are noise because they obscure finding my own diagnostics. Some library files really drown out those reported on my own files. Closing the files is obviously what I then have to manually resort to.

Also suppose you're in the workflow of having coded something and you're about to commit, but you need to tidy everything up such that it'll pass automated formatting and linters, then I typically press the keyboard shortcut for the vscode command editor.action.marker.nextInFiles to go to the first diagnostic that I "have to fix" but then it's not mine and I have to close the files on which these noisy diagnostics are reported, whereas I would rather like to say, "don't diagnose my global python installation".

This is not checked into or shared with other developers, mostly for non-technical reasons, but aside from those, source files resolution or PYTHONPATH are local affairs, I'd say.

Thank you, and hope this helps.

[erictraut]

Thanks for the additional details. I understand your use case better now. The ignore configuration setting was not designed to suppress errors for files that you happen to open outside of your workspace, and I think it would be inconsistent (and not keeping with the design of this setting) to allow paths outside of the workspace.

It sounds like what you really want is some global setting that indicates that you never want to see any errors for code files outside of your workspace regardless of their path.

I think the best thing to do here is to transfer this issue to the pylance repo. It's not really a core type checking issue and is related more to the language server functionality and settings. I'd like to get input from the broader pylance team to see if they have any better suggestions for how to address this use case. It would also be interesting to hear from other users if they have a similar need.

[jaymegordo]

I have this exact same issue and it is very frustrating.

Specifically, sometimes I need to open up files from other packages in my environment (poetry) to see what they're doing, troubleshooting etc.

I have no control over their type checking/formatting etc so I'd like to be able to just view them without 100 red problems being shown.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.