Don't show settingsNotOverridable if vscode settings file has a larger scope than the current project

[laundmo]

I have a few python.analysis settings in my user settings.json in vscode. I use these for projects which do not specify pylance settings in pyproject.toml. This means i cannot remove these lines from my user settings.json without affecting a lot of projects.

These lines are being reported as settingsNotOverridable when a project is opened which does have a pyproject.toml. This is quite annoying, as they show up in the same context as problems with my projects code.

I'm not sure what a viable solution to this is, but settingsNotOverridable should not happen for user/global settings.json. It only makes sense for project-specific settings.json.

[rchiodo]

The global settings won't apply in the current workspace, so it makes sense for the error to show up there too. Maybe we should change the wording on the error message.

[laundmo]

i'm aware it wont apply. Making that an error makes no sense to me.

I don't get errors when overwriting other user settings in a workspace settings.json. So why shoupd i get errors overwriting these specific ones with a project config?

no other vscode extension works like this. its just annoying error messages where none are needed.

[rchiodo]

Because the errors indicate your settings don't work. Regardless of where they are, if there is a pyrightconfig.json file, no settings.json settings will apply (for the settings that come from pyrightconfig.json). So it doesn't matter if they're global or if they're in a workspace settings.json, they don't get applied to Pylance.

I think I'm misunderstanding your issue. Do you not want to know that your settings won't apply? As in you don't care? Maybe it should be a warning instead of an error.

[laundmo]

Do you not want to know that your settings won't apply?

Well, yeah? It's what basically all other tools do. Hierarchical configs are extremely common and basically never lead to warnings/errors about their intended behaviour - more specific config files overwriting less specific ones.

Let's look at default VS Code behaviour:
There are actually up to 4 levels of settings

• default
• application
• user/profile
• workspace

I'll use workspace and user/profile since the others have various special cases

If I define "editor.wordWrap"="off" in my profile settings, and "editor.wordWrap"="on" in my workspace settings (.vscode/settings.json in repo) it also doesn't warn me my profile settings won't apply. It doesn't even grey it out like it does for unrecognized settings.

It's the same with any hierarchical configuration I'm aware of. There are no errors or warnings if a more specific config changes the more general one. Pylance is the first tool which I've come across which does this, and the fact that it shows up like a problem with my project, the same way, for example, type errors would, is annoying.

I just always have these errors sitting there which are reported the exact same way as errors I SHOULD fix, but these I CANNOT fix. They clutter the problems tab and force me to scroll down to reach actual problems.

[rchiodo]

Seems like these errors should be warnings (or grayed out somehow) in the global settings then. Cause the settings are likely are on purpose, so you shouldn't be removing those settings as you said.

[heejaechang]

FYI, other tool, it will merge settings based on hierarchy. but for pyproject/pyrightconfig, those settings will be completely replaced and that's the behavior difference compared to other settings.

for example, other tools, if user setting has option = true and workspace setting has no mention of option, then option = true from user setting will be applied. that's not the case for those settings you got the errors, default value will be applied instead of what you have set in user setting (replace vs merge)

[laundmo]

FYI, other tool, it will merge settings based on hierarchy. but for pyproject/pyrightconfig, those settings will be completely replaced and that's the behavior difference compared to other settings.

for example, other tools, if user setting has option = true and workspace setting has no mention of option, then option = true from user setting will be applied. that's not the case for those settings you got the errors, default value will be applied instead of what you have set in user setting (replace vs merge)

Ah, now I understand why an error here might be warranted. That's quite unintuitive, and the error message is unclear on this (the same message would work as errors for hierarchical settings).

Could you link to the discussion where it was decided to implement it like this, instead of the normal hierarchical behavior, which is much more common and intuitive? I'm curious what the reasoning was, as I question the utility of doing it this way. I may well want to use my own version of settings if the repo only partially sets them.

There could even be a setting which is only allowed in pyrightconfig.json or pyproject.toml which forces this non-hierarchical behavior for projects which want to entirely configure pylance/pyright. But right now, I'm at a loss how I would provide only some modified settings to pylance/pyright while keeping what the developer has set in their own config intact. I just wanted to change some few severities which are important for the project to "error" - if other devs want more or less, they should be free to do so.

[rchiodo]

The reasoning behind the pyrightconfig.json being the one source of truth was that it's similar to a makefile. You wouldn't want a local developer to have their own include file paths because then when they pushed, the CI would likely fail.

I'm not sure if a pyrightconfig.json would count the same way as a makefile. Code doesn't work if it doesn't compile in C++. Python code can continue to work regardless of type checking errors.

I like the idea of a way to allow hierarchical mode (instead of pyrightconfig.json being the only source). I think there's also a problem with implicit defaults in pyrightconfig.json. Just because you add exclude paths that everybody shares, doesn't mean you want everybody to default their typeCheckingMode.

[laundmo]

except its not just file paths, but also the strictness of the linting.

sure, include paths it doesn't make sense to be hierarchical (except maybe it does as different systems are set up differently. and with a repo forcing certain paths also comes a lack of flexibility relating to how python is installed)

but for which lints are error vs warn, hierarchical makes sense.

[debonte]

This issue has been fixed in prerelease version 2024.10.100, which we've just released. You can find the changelog here: CHANGELOG.md