VSCode setting should be overriden by discovered toml

[celynw]

Currently, extension settings override those which would be picked up in a pyproject.toml/ruff.toml. This was highlighted in #3:

Yeah, that's correct -- the pyproject.toml in the project path doesn't override the settings from the VS Code extension. Which is not ideal, for the reasons you described.

The best way to solve this today is to use a user-specific pyproject.toml rather than going through the VS Code extension. For example, if you're on macOS, you can create a pyproject.toml at ~/Library/Application\ Support/ruff/pyproject.toml. Then, when linting, if Ruff can't find a pyproject.toml in the current file path, it will use that as the default settings.

This is still the case (in my testing), but I'm surprised not to see another issue covering this (happy to be corrected!) I think there should at least be an issue to track this one.

Environment

• Ruff extension version v2024.16.0 (ruff==0.3.1)
• VSCode version 1.87.2
• OS: Ubuntu 22.04.4

Tested simply with line-length = 120 in ruff.toml, and --line-length=120 in VSCode setting ruff.lint.args

[MichaReiser]

I think this needs some design work on the intended behavior (CC: @snowsignal). To me, the VS code settings taking precedence over the project settings seem reasonable, or at least I could see where the opposite behavior is the intended behavior. It also opens the question if this should apply to all options or only some (e.g. what if I configure an additional configuration?) But I agree that what you're asking for makes sense, too; ultimately, the experience between IDE and CLI should be consistent, and that is only guaranteed by giving the project. to a higher priority.

[celynw]

My use case is that I have synchronised VSCode settings everywhere. I'd like to be able to open different projects which each contain a pyproject.toml file. I either have to keep my 'master' synchronised Ruff VSCode settings empty, or I have to create a workspace settings file (under .vscode/settings.json) explicitly setting those settings to be empty, overriding my 'master' synced settings and allowing the toml file to do something.

But yes, I do see why one might expect the VSCode setting to take precedence instead!

[snowsignal]

I'd support having a flag in the extension that lets discovered configuration take precedence. We'll look into solving this as we work on configuration for the upcoming VSCode extension based on our new Rust-based LSP.

[dhruvmanila]

This is possible now with the new ruff.configurationPreference editor setting.

[beauxq]

This is possible now with the new ruff.configurationPreference editor setting.

Thanks for this.

I would recommend changing it to be the default. It was pretty unexpected for it not to work this way, and it's different from other tools like pyright. If pyright finds a text configuration file (either [tool.pyright] in pyproject.toml or pyrightconfig.json), it uses that and ignores what is in VSCode settings, and this was never surprising to me.

With this Ruff extension, I was confused and surprised and had trouble figuring out what was going on.

[T-256]

I would recommend changing it to be the default.

In addition to change ruff-vscode, here is the native server related code that needs to be changed:

https://github.com/astral-sh/ruff/blob/b9c8113a8a80a464fd042f290553817d8024fdfc/crates/ruff_server/src/session/settings.rs#L50-L58

[dhruvmanila]

I would recommend changing it to be the default. It was pretty unexpected for it not to work this way, and it's different from other tools like pyright. If pyright finds a text configuration file (either [tool.pyright] in pyproject.toml or pyrightconfig.json), it uses that and ignores what is in VSCode settings, and this was never surprising to me.

I've opened https://github.com/astral-sh/ruff/issues/13067 to track that.