Introduce LinterSettings

[MichaReiser]

Stack Summary

This stack splits Settings into FormatterSettings and LinterSettings and moves it into ruff_workspace. This change is necessary to add the FormatterSettings to Settings without adding ruff_python_formatter as a dependency to ruff_linter (and the linter should not contain the formatter settings).

A quick overview of our settings struct at play:

• Options: 1:1 representation of the options in the pyproject.toml or ruff.toml. Used for deserialization.
• Configuration: Resolved Options, potentially merged from multiple configurations (when using extend). The representation is very close if not identical to the Options.
• Settings: The resolved configuration that uses a data format optimized for reading. Optional fields are initialized with their default values. Initialized by Configuration::into_settings .

The goal of this stack is to split Settings into tool-specific resolved Settings that are independent of each other. This comes at the advantage that the individual crates don't need to know anything about the other tools. The downside is that information gets duplicated between Settings. Right now the duplication is minimal (line-length, tab-width) but we may need to come up with a solution if more expensive data needs sharing.

This stack focuses on Settings. Splitting Configuration into some smaller structs is something I'll follow up on later.

PR Summary

This PR extracts the linter-specific settings into a new LinterSettings struct and adds it as a linter field to the Settings struct. This is in preparation for moving Settings from ruff_linter to ruff_workspace

Test Plan

cargo test

[MichaReiser]

Current dependencies on/for this PR:

• main
  • PR Unify Settings and AllSettings #7532
    • PR Extract ResolverSettings #7542
      • PR Introduce LinterSettings #7543 👈
        • PR Move Settings and ResolverSettings to ruff_workspace #7544
          • PR Introduce FormatterSettings #7545
            • PR Create LintConfiguration #7548
              • PR Add lint section to Ruff configuration #7549
    • PR Rename ConfigProcessor to ConfigurationTransformer #7536

This comment was auto-generated by Graphite.

[MichaReiser]

The changes in this file are the main changes. Everything else are just downstream refactors to use the new structure.

[charliermarsh]

I feel like some of these aren't linter-specific, like namespace_packages and src -- they would be generally applicable to any tool that does module / file resolution. But it's not important for now.

[MichaReiser]

That's true, but the Settings are the resolved view for a tool. My current, not so nice approach, is to duplicate settings that apply to multiple tools when resolving the Configuration. Meaning, the Configuration applies` the right inheritance rules and, as a result, may end up initializing common fields identically.

I don't think this is a performance problem because we only do this once per setting and settings tend to not have very large structures.

[charliermarsh]

Should this be lifted up?

[MichaReiser]

The linter needs access to target_version. We can't access it if we lift it up. I'll lift it up in the Configuration, but the each Setting object needs its own copy of the target_version.

[codspeed-hq]

CodSpeed Performance Report

Merging #7543 will improve performances by 2%

_{Comparing linter-settings (308bae8) with main (8f41eab)}

Summary

⚡ 1 improvements
✅ 24 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	linter-settings	Change
⚡	linter/default-rules[pydantic/types.py]	38.8 ms	38 ms	+2%

[MichaReiser]

Merge Activity

• Sep 20, 10:41 AM: Graphite rebased this pull request after merging its parent, because this pull request is set to merge when ready.
• Sep 20, 11:02 AM: @MichaReiser merged this pull request with Graphite.

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.