Add most formatter options to ruff.toml / pyproject.toml

[MichaReiser]

Summary

This PR adds most formatter configuration options under a new [format] section.

Missing options

• Tab size
• Respecting exclude

Closes #7061
Closes #7570

Open Questions

• Should we add line-ending as a global configuration option similar to line-width and tab-size to that Styleist could use it to. My main hesitation is that the formatter should default to LineEnding::Lf, but Styleist uses LineEnding::Auto (which makes sense for a linter).
• Naming of LineEnding options: Are people familiar with Lf and CrLf or should we use Unix and Windows

Test Plan

• I added a few integration tests.
• Unfortunately, it seems insta-cmd normalizes line endings in snapshots (makes sense). So I used a hex viewer to verify that cr-lf results in \r\n line endings
• I played around with the settings in the Playground

[MichaReiser]

Current dependencies on/for this PR:

• main
  • PR Add most formatter options to ruff.toml / pyproject.toml #7566 👈
    • PR Refactor Options representation #7591
      • PR Support option group documentation #7593
        • PR Add lint section to Ruff configuration #7549
          • PR Rename ConfigurationOptions derive macro to OptionsMetadata #7599

This comment was auto-generated by Graphite.

[MichaReiser]

I had to move the file because FiltePatternSet and FilePattern is defined in ruff_linter. We may want to introduce a new crate for these types eventually but moving the struct to ruff_workspace is sufficient for now because the formatter doesn't use it.

[codspeed-hq]

CodSpeed Performance Report

Merging #7566 will degrade performances by 3.15%

_{Comparing format-options (7a13d26) with main (82978ac)}

Summary

❌ 1 regressions
✅ 24 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	format-options	Change
❌	linter/default-rules[large/dataset.py]	91.1 ms	94.1 ms	-3.15%

[MichaReiser]

Using untagged allows us to support both the old SerializationFormat and Format group. The only downside is that serde's error messages aren't any useful because it only tells you that what you have is neither of the two.

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

[konstin]

What about the following semantics for a global line-ending?

• line-ending = "auto"

  • i'm using only the linter: line endings are determined from what the file already uses
  • i'm also using the formatter: line endings are changed to LF everywhere

• line-ending = "native"/"lf"/"cr-lf"

  • i'm using only the linter: line endings are set to native/lf/cr-lf
  • i'm also using the formatter: line endings are changed to native/lf/cr-lf everywhere

By default, if a user only uses the linter, they get the usual conservative linter behaviour that tries to match what is already there, and won't notice the more aggresive formatter behaviour. If they use the formatter they get maximized consistency, since the formatter runs after the linter, user don't need to care about the preservation attempt in the linter. If a user has specific wishes, they can specify. Depending on their git and editor configuration, they also have the native option to keep the platform behaviour.

The formatter section documentation will link all global options that impact formatting style.

[MichaReiser]

What about the following semantics for a global line-ending?

* line-ending = "auto"
  
  * i'm using only the linter: line endings are determined from what the file already uses
  * i'm also using the formatter: line endings are changed to LF everywhere

* line-ending = "native"/"lf"/"cr-lf"
  
  * i'm using only the linter: line endings are set to native/lf/cr-lf
  * i'm also using the formatter: line endings are changed to native/lf/cr-lf everywhere

By default, if a user only uses the linter, they get the usual conservative linter behaviour that tries to match what is already there, and won't notice the more aggresive formatter behaviour. If they use the formatter they get maximized consistency, since the formatter runs after the linter, user don't need to care about the preservation attempt in the linter. If a user has specific wishes, they can specify. Depending on their git and editor configuration, they also have the native option to keep the platform behaviour.

The formatter section documentation will link all global options that impact formatting style.

The challenge is that we don't know whether someone uses the formatter other than when they run ruff format or explicitly opt out of formatting using format.enabled = false.

I would also try to make settings as static as possible to avoid confusion. E.g. what happens if formatting is only used in some directories? Does Auto then have the same semantics for all files or depends on whether the file gets formatted?

[konstin]

The challenge is that we don't know whether someone uses the formatter other than when they run ruff format or explicitly opt out of formatting using format.enabled = false.

I would also try to make settings as static as possible to avoid confusion. E.g. what happens if formatting is only used in some directories? Does Auto then have the same semantics for all files or depends on whether the file gets formatted?

Assuming that if we run the formatter, we run it consistently after the linter, i don't think either of this is a problem: Files that get formatted get LF consistency, files that are not formatted have their line endings preserved by the linter. Put differently, i think the default should be the linter doesn't change any line endings (wrt to the file it's fixing), while the formatter changes all line endings.

[qarmin]

Default format configuration should be added here - https://github.com/astral-sh/ruff#configuration

[MichaReiser]

The challenge is that we don't know whether someone uses the formatter other than when they run ruff format or explicitly opt out of formatting using format.enabled = false.
I would also try to make settings as static as possible to avoid confusion. E.g. what happens if formatting is only used in some directories? Does Auto then have the same semantics for all files or depends on whether the file gets formatted?

Assuming that if we run the formatter, we run it consistently after the linter, i don't think either of this is a problem: Files that get formatted get LF consistency, files that are not formatted have their line endings preserved by the linter. Put differently, i think the default should be the linter doesn't change any line endings (wrt to the file it's fixing), while the formatter changes all line endings.

I agree with this and I think this aligns with only having line-ending under format.

[MichaReiser]

Default format configuration should be added here - astral-sh/ruff#configuration

Thanks for calling this out. I wasn't aware that we list the defaults in the README. I'm unsure yet what we should do about this, considering that the formatter options are preview only. I'll ask internally

[MichaReiser]

Default format configuration should be added here - astral-sh/ruff#configuration

We discussed this internally. We wait with adding the section until reaching beta / stable.