-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add most formatter options to ruff.toml
/ pyproject.toml
#7566
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 Performance ReportMerging #7566 will degrade performances by 3.15%Comparing Summary
Benchmarks breakdown
|
@@ -2381,11 +2390,141 @@ impl PyUpgradeOptions { | |||
} | |||
} | |||
|
|||
#[derive(Debug, PartialEq, Eq, Serialize, Deserialize)] | |||
#[serde(untagged)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
eb3bf39
to
4cce790
Compare
4cce790
to
e27ee67
Compare
PR Check ResultsEcosystem✅ ecosystem check detected no changes. |
What about the following semantics for a global
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 |
The challenge is that we don't know whether someone uses the formatter other than when they run 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 |
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. |
e27ee67
to
bc3127d
Compare
Default format configuration should be added here - https://github.com/astral-sh/ruff#configuration |
I agree with this and I think this aligns with only having |
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 |
bc3127d
to
effaf85
Compare
We discussed this internally. We wait with adding the section until reaching beta / stable. |
effaf85
to
a5e2a14
Compare
a5e2a14
to
7a13d26
Compare
Summary
This PR adds most formatter configuration options under a new
[format]
section.Missing options
exclude
Closes #7061
Closes #7570
Open Questions
line-ending
as a global configuration option similar toline-width
andtab-size
to thatStyleist
could use it to. My main hesitation is that the formatter should default toLineEnding::Lf
, butStyleist
usesLineEnding::Auto
(which makes sense for a linter).LineEnding
options: Are people familiar withLf
andCrLf
or should we useUnix
andWindows
Test Plan
insta-cmd
normalizes line endings in snapshots (makes sense). So I used a hex viewer to verify thatcr-lf
results in\r\n
line endingsPlayground