Feature suggestion: global, system wide configuration file

[Terseus]

The documentation states the following ways to configure basedpyright:

• a "pyrightconfig.json" file located in the root of the project.
• the section [tool.basedpyright] in the "pyproject.toml" file, also in the root of the project.

This forces the user that doesn't want to use the default settings to configure each project separately, which is a burden, especially when you change the configuration over time.

I understand that this limitation is inherited from pyright.

It would be great if basedpyright support a global configuration file in $XDG_CONFIG_HOME, defaulting to $HOME/.config, e.g. $XDG_CONFIG_HOME/basedpyright/pyrightconfig.json, following the common standard rules for applications with support for different config files:

• the global configuration and per-project configuration should be merged together.
• in case of conflict, the per-project configuration should always take precedence over the global configuration.

[KotlinIsland]

One of the most important features we view is that a tools behaviour should be consistent across local development and the CI. Seeing errors from someone else's change because it doesn't match your preferred local stricter configuration does not sound like a good experience.

What about we also support config merging at a generic level, then a config could be hosted on GitHub for example, then the project can reference this centralised configuration?

[DetachHead]

if you use vscode, you can set the typeCheckingMode and diagnosticSeverityOverrides the user scope:

[Terseus]

@KotlinIsland I understand your POV, however I think the main usage of an LSP is in a developer environment and thus find reasonable this use case to be the main focus of the tool.

@DetachHead I don't use VSCode, sorry, I'm using Neovim.

My motivation for this feature is to migrate from pyright with ease.

Pyright's out of the box behavior is different than basedpyright, so just switching to basedpyright causes some problems (e.g. see https://github.com/DetachHead/basedpyright/issues/168), having the ability to create a global configuration file to match pyright's behavior makes migrating much more pleasant than having to create (and maintain) configuration files in multiple projects.

I have more than 20 Python repositories in my work, this is the only issue preventing me to migrate.

[DetachHead]

to clarify, the issue is that the default settings for basedpyright don't match your preferences, so you need to change the settings in every project because there's no global configuration. and this isn't an issue in pyright because you're happy with its default settings?

in that case, i guess we could support a config file at ~/pyrightconfig.json or something (though i'm not familiar with the $XDG_CONFIG_HOME environment variable you mentioned. would having the config file in the home directory work for you?)

[KotlinIsland]

So, you want to see a certain configuration of inspections in your local development, but you have no interest in enforcing them in your project(CI)?

Personally I don't think that's a good practice, even if your the only one working on a project.

I can understand though, if you were using pyright and the different defaults in basedpyright are causing friction.

If @DetachHead's suggestion doesn't resolve the problem, do you think that adding the small amount of configuration to each project to set the inspection configuration to pyright's level is too much?

[Terseus]

@DetachHead

to clarify, the issue is that the default settings for basedpyright don't match your preferences,

Not my personal preference but most of the pyright's defaults, which as I said before it causes friction when migrating from it to basedpyright. I understand this kind of migration is the main source of users to basedpyright, so it makes sense to do it as seamless as possible without having to match pyright's defaults.

in that case, i guess we could support a config file at ~/pyrightconfig.json or something (though i'm not familiar with the $XDG_CONFIG_HOME environment variable you mentioned. would having the config file in the home directory work for you?)

Having the config file in the home path is not a good idea, when a lot of tools do it this ends cluttering their users' home, that's why most people prefer $HOME/.config instead.

As for $XDG_CONFIG_HOME it's an environment variable from the XDG base spec.

Here you can have a deeper explanation for mot using the $HOME for config files: https://xdgbasedirectoryspecification.com/

@KotlinIsland

do you think that adding the small amount of configuration to each project to set the inspection configuration to pyright's level is too much?

It's not the amount of configuration but the number of config files.

Being a new tool it's highly probable that users tweak their configuration over time until they hit their sweet spot, not having a single system wide config file makes this process much more painful than it should be IMHO.

Anyway, I think having a global config file it's a common feature of developr tools that may enable other use cases.

[DetachHead]

Having the config file in the home path is not a good idea, when a lot of tools do it this ends cluttering their users' home, that's why most people prefer $HOME/.config instead.

As for $XDG_CONFIG_HOME it's an environment variable from the XDG base spec.

Here you can have a deeper explanation for mot using the $HOME for config files: https://xdgbasedirectoryspecification.com/

so i guess what it should do is check for the $XDG_CONFIG_HOME environment variable and, if it exists, check for the config in $XDG_CONFIG_HOME/pyrightconfig.json. otherwise, check for the config in $HOME/.config/pyrightconfig.json

i'm a windows user so i'm quite unfamiliar with this stuff. from my understanding this standard is not relevant to windows at all. so it could just check for %APPDATA%/pyrightconfig.json or something instead of using those environment variables.

[Terseus]

@DetachHead

i'm a windows user so i'm quite unfamiliar with this stuff. from my understanding this standard is not relevant to windows at all. so it could just check for %APPDATA%/pyrightconfig.json or something instead of using those environment variables.

I'm not familiar with Windows so I've checked other modern applications:

• Neovim uses %LOCALAPPDATA%\nvim\init.lua: https://github.com/neovim/neovim/issues/9352
• VSCode uses %APPDATA%\Code\User\settings.json: https://code.visualstudio.com/docs/getstarted/settings
• Alacritty uses %APPDATA%\alacritty\alacritty.toml: https://github.com/alacritty/alacritty
• Rclone uses %APPDATA%\rclone\rclone.conf: https://rclone.org/docs/#config-config-file

I would use %APPDATA%\basedpyright\pyrightconfig.json, I like to have a directory to store the application files (even if it's only planned to be one).

[miversen33]

As an alternative, maybe it makes sense to allow users to provide configuration options directly to the LSP on init? I don't know how the vscode extension handles this but I know neovim already has the scaffolding in place (see nvim-lspconfig). The main issue is that this seems to only currently accept lsp specific options and we cannot (at least I can't?) pass through my "ide specific configuration" to basedpyright without creating these project specific files. Going this route actually means that you don't need to check for a global file at all either as the configurations are passed to you directly (I assume things like vscode save those configurations somewhere and indicate to the LSP where to find them via a startup flag or even just text in an argument?).

While I can appreciate the cli aspect here, it makes so much sense as a developer to allow your users to provide a global configuration of some kind to allow them to have a consistent experience across projects that don't enforce their own lsp and configuration guidelines.

Note: I have very little experience playing with the underbelly of LSPs so I could be spouting nonsense, please tell me if that is true

[Terseus]

@miversen33 While it's true that it should be equivalent to pass the configuration to the LSP directly, some editors/IDEs may not make it easy to access to this mechanism, while having a global configuration file will make it accessible to every user, no matter what stack they're using with basedpyright.