--config as a global flag/env var

[abbec]

Hi,

Thanks for a great tool! However, it would be super great if the --config flag could be passed globally. I.e. that all commands accepted it but did not use it. We are generating the ruff config and wrapping the tool execution in a script and currently we have to parse the subcommand to know when to add --config or not. An environment variable to control the config file would also work fine.

[abbec]

Also noticed that some global flags (like -v) does not work with some subcommands:

$ ruff -v rule
[2024-02-08][10:52:40][ruff_cli::resolve][DEBUG] Using Ruff default settings
[2024-02-08][10:52:40][ruff_cli::commands::check][DEBUG] Identified files to lint in: 450.238µs
[2024-02-08][10:52:40][ruff_cli::commands::check][DEBUG] Checked 1 files in: 35.4µs
rule:1:1: E902 No such file or directory (os error 2)
Found 1 error.

so it looks like it is trying to run check on a file called rule because I added the -v flag (-q behaves the same).

[charliermarsh]

I think this might be solved in the next release via #9599, which lets you pass any argument via the --config flag. E.g., you can pass --config "lint.isort.combine-as-imports=false". Does that work for you?

Separately... the ruff -v rule thing is a really specific failure, which is that when we added subcommands (like ruff check), we kept ruff /path/to/file.py working for backwards-compatibility. So if you pass some non-subcommand, then Ruff thinks you're trying to check a file named -v. (We'll fix this in the future when we deprecate calling ruff without a subcommand.)

[abbec]

Unless I have missed something, I do not think so. We need a way to wrap the ruff binary such that we can always pass the --config flag without implementing our own subcommand parsing. Think of our wrapper as a "ruff but with this config instead of the default".

[charliermarsh]

Can I ask what subcommands you're running?

[abbec]

All of them. I.e. we expose a wrapped ruff executable so that users can use like it was the original ruff, only with our default config. Alas, they might run ruff version, ruff check or ruff linter. We just want to make sure that all users get a default config.

[AlexWaygood]

I quite like pytest's solution to this problem — they allow arbitrary CLI options to be set using the PYTEST_ADDOPTS environment variable: https://docs.pytest.org/en/7.1.x/example/simple.html

[MichaReiser]

My main concern with fancy environment option inheritance is that it can feel rather magic and is hard to debug. I've run into this more than once myself where I forgot that I set some env variable and couldn't figure out why a tool isn't behaving the way I expect it.

This can be mitigated by providing better debugging tools explaining from where ruff takes which options but this is something I haven't seen in any tool today.

[abbec]

In our case it does not have to be environment either. But the other tools we use (pytest, mypy, black pylint, flake8) can be passed their equivalent --config parameter regardless of which subcommand/flags are used.

[MichaReiser]

Making --config a global option makes sense to me

[alan-isaac]

Separately... the ruff -v rule thing is a really specific failure, which is that when we added subcommands (like ruff check), we kept ruff /path/to/file.py working for backwards-compatibility. So if you pass some non-subcommand, then Ruff thinks you're trying to check a file named -v. (We'll fix this in the future when we deprecate calling ruff without a subcommand.)

This was really confusing until I found this issue. Simply reporting the name of the file not found as part of the error message would have helped pin things down.