Allow arbitrary configuration options to be overridden via the CLI #9599
Conversation
There was a problem hiding this comment.
Nice! I haven't done a full review and only skimmed through the code.
Some CLI tests showing how overrides work for check and format, including some advanced use cases like specifying values for a table (e.g is there a way to "append" to --per-file-ignores without having to use a JSON value?) Can I do --config "per-file-ignores.__init__.py" = ["RUF100"]? See ruff/tests/format or /ruff/tests/lint etc for examples.
Previously, without the 'wrap_help' feature enabled, Clap would not do any auto-wrapping of help text. For help text with long lines, this tends to lead to non-ideal formatting. It can be especially difficult to read when the width of the terminal is smaller. This commit enables 'wrap_help', which will automatically cause Clap to query the terminal size and wrap according to that. Or, if the terminal size cannot be determined, it will default to a maximum line width of 100. Ref #9599 (comment)
Previously, without the 'wrap_help' feature enabled, Clap would not do any auto-wrapping of help text. For help text with long lines, this tends to lead to non-ideal formatting. It can be especially difficult to read when the width of the terminal is smaller. This commit enables 'wrap_help', which will automatically cause Clap to query the terminal size and wrap according to that. Or, if the terminal size cannot be determined, it will default to a maximum line width of 100. Ref #9599 (comment)
Previously, without the 'wrap_help' feature enabled, Clap would not do any auto-wrapping of help text. For help text with long lines, this tends to lead to non-ideal formatting. It can be especially difficult to read when the width of the terminal is smaller. This commit enables 'wrap_help', which will automatically cause Clap to query the terminal size and wrap according to that. Or, if the terminal size cannot be determined, it will default to a maximum line width of 100. Ref #9599 (comment)
Previously, without the 'wrap_help' feature enabled, Clap would not do any auto-wrapping of help text. For help text with long lines, this tends to lead to non-ideal formatting. It can be especially difficult to read when the width of the terminal is smaller. This commit enables 'wrap_help', which will automatically cause Clap to query the terminal size and wrap according to that. Or, if the terminal size cannot be determined, it will default to a maximum line width of 100. Ref #9599 (comment)
|
CodSpeed Performance ReportMerging #9599 will not alter performanceComparing Summary
|
|
Thanks so much @zanieb! I think I tackled nearly all of your points, except for #9599 (comment) where we're waiting for Charlie to chime in. Some of the error messages might still be a bit verbose for your liking, but I'm not sure how to trim them down... suggestions welcome :) |
|
Sorry, didn't realize this was waiting on me! I'll take a look today, then we should merge :) |
|
|
||
| // small hack so that multiline tips | ||
| // have the same indent on the left-hand side: | ||
| let tip_indent = " ".repeat(" tip: ".len()); |
There was a problem hiding this comment.
A little concerning how much implicit coupling there is to Clap, but I don't have better suggestions (and at least there's test coverage, I think, such that if we upgrade Clap and the output format changes, we will know that there's a disconnect here).
There was a problem hiding this comment.
Yeah. Ideally I feel like clap would have a feature that allows long error messages to be wrapped to the terminal width, much as it does with the output of --help. But it doesn't seem to have that feature right now :/
Initially I had each sentence as a separate tip, which obviated the need for this kind of hack, but Zanie (correctly!) pointed out that that looked pretty weird
|
Thanks all for the reviews! I'll land this now |
|
For posterity: #10035 |
## Summary When users provide configurations via `--config`, we use `shellexpand` to ensure that we expand signifiers like `~` and environment variables. In #9599, we modified `--config` to accept either a path or an arbitrary setting. However, the detection (to determine whether the value is a path or a setting) was lacking the `shellexpand` behavior -- it was downstream. So we were always treating paths like `~/ruff.toml` as values, not paths. Closes astral-sh/ruff-vscode#413.
…stral-sh#9599) Fixes astral-sh#8368 Fixes astral-sh#9186 ## Summary Arbitrary TOML strings can be provided via the command-line to override configuration options in `pyproject.toml` or `ruff.toml`. As an example: to run over typeshed and respect typeshed's `pyproject.toml`, but override a specific isort setting and enable an additional pep8-naming setting: ``` cargo run -- check ../typeshed --no-cache --config ../typeshed/pyproject.toml --config "lint.isort.combine-as-imports=false" --config "lint.extend-select=['N801']" ``` --------- Co-authored-by: Micha Reiser <[email protected]> Co-authored-by: Zanie Blue <[email protected]>
## Summary When users provide configurations via `--config`, we use `shellexpand` to ensure that we expand signifiers like `~` and environment variables. In astral-sh#9599, we modified `--config` to accept either a path or an arbitrary setting. However, the detection (to determine whether the value is a path or a setting) was lacking the `shellexpand` behavior -- it was downstream. So we were always treating paths like `~/ruff.toml` as values, not paths. Closes astral-sh/ruff-vscode#413.
Fixes #8368
Fixes #9186
Summary
Arbitrary TOML strings can be provided via the command-line to override configuration options in
pyproject.tomlorruff.toml. As an example: to run over typeshed and respect typeshed'spyproject.toml, but override a specific isort setting and enable an additional pep8-naming setting:This is what the error message currently looks like if you provide an invalid
--configoption:Test Plan
So far, just manual testing. TODO: write proper tests and docs.Several tests added to
crates/ruff/tests/format.rsandcrates/ruff/tests/lint.rs. Also, extensive manual testing.