VSCode setting should be overriden by discovered toml

[Celyn Walters]

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

[Micha Reiser]

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.

[Celyn Walters]

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!

[Jane Lewis]

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.