priority between pyproject.toml ignore=[...] and --extend-select?

[PerMildner]

If the pyproject.toml have ignore = [ "E501" ], and ruff is invoked (by the VSCode plugin v2024.30.0), with --extend-select=E501, the documentation does not say "who will win", i.e. whether E501 issues will be reported.

I looked at Configuring VSCode and Configuring Ruff but it has no information about how conflicting options are resolved.

I do not know whether this is "just" missing documentation, or whether this is a bug in behavior.

In our case, we would like the CI (which only uses pyproject.toml) to ignore E501 (overlong lines) but we want the VSCode linter to warn about E501, so we would prefer that --extend-select overrides any settings in pyproject.toml but that does not seem to be what it happening.

[charliermarsh]

Are you using nativeServer: true or not?

[PerMildner]

I am using whatever is the default, i.e. currently not the new Rust-based native server. The only Ruff-specific setting in our (Dev container-based) settings is "editor.defaultFormatter": "charliermarsh.ruff".

[charliermarsh]

My expectation then is that the configuration you described should behave the way you want. I can give it a try myself.

[dhruvmanila]

If the pyproject.toml have ignore = [ "E501" ], and ruff is invoked (by the VSCode plugin v2024.30.0), with --extend-select=E501, the documentation does not say "who will win", i.e. whether E501 issues will be reported.

The documentation for this is at https://docs.astral.sh/ruff/linter/#rule-selection, specifically this line:

CLI options are given higher priority than pyproject.toml options, and the current pyproject.toml file is given higher priority than any inherited pyproject.toml files.

I agree that it's a bit hidden.

I can confirm that it should work with the following settings:

VS Code settings.json:

{
  "ruff.nativeServer": false,
  "ruff.lint.args": [
    "--extend-select=E501"
  ],
}

And, pyproject.toml:

[tool.ruff]
line-length = 30

[tool.ruff.lint]
ignore = ["E501"]

And, if I comment out the ruff.lint.args from settings.json, the warning goes away.

[dhruvmanila]

that does not seem to be what it happening.

Can you specify what exactly isn't happening? Is it either the CI or the editor that is not warning about E501?

[PerMildner]

@dhruvmanila: The VSCode editor is not warning about overlong lines.

Thank you all for looking at this and for clarifying that it is supposed to work as I had hoped, and for pointing me at the relevant documentation.

I will investigate some more to verify that this is not just PEBKAC on my part. Also, my use case is in a devcontainer, and I have noticed some other problems with that setup, so perhaps it is a devcontainer-only problem.

In either case, it would be good if the documentation was more "in your face", i.e. less hidden, about what to expect when combining (conflicting) options.

[dhruvmanila]

Also, my use case is in a devcontainer, and I have noticed some other problems with that setup, so perhaps it is a devcontainer-only problem.

Sorry, I wasn't aware that the problem you're facing is in a devcontainer. As you've noticed, there have been some reports around Ruff running in devcontainer.

In either case, it would be good if the documentation was more "in your face", i.e. less hidden, about what to expect when combining (conflicting) options.

I hear you. In this case, I think a bulleted list would help.

Thank you for the feedback!

[PerMildner]

The plot thickens.

I changed our devcontainer.json and pyproject.toml according to the comment above.

The devcontainer.json now has:

{
    ...
    "customizations": {
        "vscode": {
            "extensions": [
                "ms-python.python",
                "charliermarsh.ruff",
        "redhat.ansible"
            ],
            "settings": {
                "extensions.verifySignature": false,
                "telemetry.enableTelemetry": false,
                "python.defaultInterpreterPath": "${workspaceFolder}/.venv",
                "git.autoRepositoryDetection": true,
                "git.openRepositoryInParentFolders": "always",
        "[python]": {
            "editor.defaultFormatter": "charliermarsh.ruff",

            // <https://github.com/astral-sh/ruff-vscode/issues/515#issuecomment-2208164597>
            "ruff.nativeServer": false,
            "ruff.lint.args": [
            "--extend-select=E501"
            ],

        }
            }
        }
    },
    ...
}

What seems to happen is that the --extend-select=E501 is not passed to ruff check. So, whatever the problem is it is not with the ruff tool.

In the terminal, on the devcontainer, I have:

$ find ~ -name settings.json
/home/user/.vscode-server/data/Machine/settings.json
/home/user/.vscode-server/extensions/ms-python.python-2024.8.1/python_files/.vscode/settings.json
$ cat /home/user/.vscode-server/data/Machine/settings.json
{
        "extensions.verifySignature": false,
        "telemetry.enableTelemetry": false,
        "python.defaultInterpreterPath": "${workspaceFolder}/.venv",
        "git.autoRepositoryDetection": true,
        "git.openRepositoryInParentFolders": "always",
        "[python]": {
                "editor.defaultFormatter": "charliermarsh.ruff",
                "ruff.nativeServer": false,
                "ruff.lint.args": [
                        "--extend-select=E501"
                ]
        }
}
$ cat /home/user/.vscode-server/extensions/ms-python.python-2024.8.1/python_files/.vscode/settings.json
{"files.exclude":{"**/__pycache__/**":true,"**/**/*.pyc":true},"python.formatting.provider":"black"}

So, the --extend-select=E501 is passed from our .devcontainer.json successfully.

I look at the OUTPUT tab in VSCode, and the following replicates how ruff check is called, i.e. no --extend-select=....

$ /home/user/..redacted../.venv/bin/ruff 'check' '--force-exclude' '--no-cache' '--no-fix' '--quiet' '--output-format' 'json' '-' '--stdin-filename' '/home/user/..redacted../conftest.py' < '/home/user/..redacted../conftest.py'
[
  {
    "cell": null,
    "code": "I001",
    "end_location": {
      "column": 1,
      "row": 8
    },
    "filename": "/home/user/..redacted../tests/conftest.py",
    ...
    "message": "Import block is un-sorted or un-formatted",
    "noqa_row": 1,
    "url": "https://docs.astral.sh/ruff/rules/unsorted-imports"
  }

I.e. ruff check is clearly run (and also gives these warning in the VSCode editor).

If I add '--extend-select=E501' to the above command, then the E501 warnings appear in the output from ruff check.

[dhruvmanila]

I think I see the problem in here. The ruff.* settings are not tied to the language settings, they should be set globally. What I mean is that those settings shouldn't be under the [python] namespace. So, considering the config you've provided, the correct place to put Ruff settings would be:

{
    "customizations": {
        "vscode": {
            "extensions": [
                "ms-python.python",
                "charliermarsh.ruff",
                "redhat.ansible"
            ],
            "settings": {
                "extensions.verifySignature": false,
                "telemetry.enableTelemetry": false,
                "python.defaultInterpreterPath": "${workspaceFolder}/.venv",
                "git.autoRepositoryDetection": true,
                "git.openRepositoryInParentFolders": "always",
                // Ruff settings should be in the global namespace
                "ruff.nativeServer": false,
                "ruff.lint.args": [
                    "--extend-select=E501"
                ],
                "[python]": {
                    "editor.defaultFormatter": "charliermarsh.ruff",
                }
            }
        }
    }
}

Can you try this? I think this should work now.

[PerMildner]

Thanks for the workaround!

I can confirm that if I put the "ruff.lint.args" at the global level, the --extend-select is passed correctly to ruff check by the VSCode linting.

Interestingly, unlike some other settings (#501), even after disconnecting and re-connecting to the dev container, putting "ruff.lint.args" under "[python]" have no effect.

However, this is not documented, I think, and surely this is unexpected and a bug? (Given the problems mentioned in #501 it may be a bug in the VSCode dev-container plugin, I have no idea how VSCode works internally)

[dhruvmanila]

Good to know it's working :)

Interestingly, unlike some other settings (#501), even after disconnecting and re-connecting to the dev container, putting "ruff.lint.args" under "[python]" have no effect.

The extension settings are not part of the language namespace which is why you can't use it in there. This is a deliberate choice. Ruff only works with the Python language so there's no benefit in reading these settings from the language namespace unlike other settings like editor.codeActionsOnSave. Note that these editor.* settings are part of the VS Code editor itself and is not provided by the Ruff extension.

However, this is not documented, I think, and surely this is unexpected and a bug?

Can you specify what isn't documented? I don't this is unexpected nor a bug for the same reasons as stated in the previous paragraph.

[PerMildner]

My expectation would be that every plugin looks up any setting hierarchically, from more specific (e.g for a particular language) to less specific (i.e. global scope in settings.json).

This way I do not need to know whether a plugin (like ruff-vs) is affected by the scope or not, I just put the setting at the most precise/smallest scope, i.e. [python] in this case.

If plugins always looked for their setting hierarchically like this, my settings would be future safe, e.g. if ruff-vs starts supporting some other Python-like language (e.g. Mojo...).

It also makes it possible to keep the settings.json (or devcontainer.json) tidy, since it would allow grouping everything that has to do with a particular language under the heading of that language.

(But, as I mentioned, I have no idea how VSCode plugins are supposed to work, the above is just what I expected.)

[dhruvmanila]

That's interesting. Out of curiosity, do you know any plugin that actually does resolve the settings like the way you've mentioned? I don't think I know any extension which does that.

(I'll close this issue considering it resolved.)