Pick up pyproject.toml based on file path or workspace

[charliermarsh]

No description provided.

[TommasoAmici]

This would be quite useful for me, would you accept a PR implementing it?

EDIT: it seems like this already works actually

[charliermarsh]

I wonder how that works, I would've expected it not to since we don't use the passed-in path to infer the project root 🤔

[charliermarsh]

Oh, we pass the stdin filename, of course...

[fredrikaverpil]

@charliermarsh does this issue mean that the selected rules from pyproject.toml would supersede/take precedence over what you have in your vscode settings?

I don't think this works currently but I would really like to see this.

When working in a team where everyone has individual vscode settings, it's confusing to talk about which ruff rules you want in your project - when you don't see warnings in vscode based on the pyproject.toml for that project.
The expected behavior would be to get warnings shown to you and autofixes applied automatically for stuff that the project (pyproject.toml) desires/requires.

I appreciate that different people might desire different behavior here so maybe a ruff-vscode setting would be preferable here which makes it possible to specify which takes precedence; pyproject.toml or vscode settings.

I also posted about this over at mastodon (here).

[charliermarsh]

I don't think this works currently but I would really like to see this.

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.

[fredrikaverpil]

@charliermarsh thanks for this - great that there's this workaround. Is this pyproject.toml fallback documented somewhere?