Fallback to `requires-python` in certain cases when `target-version` is not found by dylwil3 · Pull Request #16319 · astral-sh/ruff

dylwil3 · 2025-02-22T19:14:02Z

Summary

This PR introduces the following modifications in configuration resolution:

In the event where we are reading in a configuration file myconfig with no target-version specified, we will search for a pyproject.toml in the same directory as myconfig and see if it has a requires-python field. If so, we will use that as the target-version.
In the event where...

we have not used the flag --isolated, and
we have not found any configuration file, and
we have not passed --config specifying a target version

then we will search for a pyproject.toml file with required-python in an ancestor directory and use that if we find it.

We've also added some debug logs to indicate which of these paths is taken.

Implementation

Two small things:

I have chosen a method that will sometimes re-parse a pyproject.toml file that has already been parsed at some earlier stage in the resolution process. It seemed like avoiding that would require more drastic changes - but maybe there is a clever way that I'm not seeing!
When searching for these fallbacks, I suppress any errors that may occur when parsing pyproject.tomls rather than propagate them. The reasoning here is that we have already found or decided upon a perfectly good configuration, and this is just a "bonus" to find a better guess for the target version.

Closes #14813, #16662

Testing

The linked issue contains a repo for reproducing the behavior, which we used for a manual test:

ruff-F821-repro on  main
❯ uvx ruff check --no-cache
hello.py:9:11: F821 Undefined name `anext`. Consider specifying `requires-python = ">= 3.10"` or `tool.ruff.target-version = "py310"` in your `pyproject.toml` file.
  |
8 | async def main():
9 |     print(anext(g()))
  |           ^^^^^ F821
  |

Found 1 error.

ruff-F821-repro on  main
❯ ../ruff/target/debug/ruff check --no-cache
All checks passed!

In addition, we've added snapshot tests with the CLI output in some examples. Please let me know if there are some additional scenarios you'd like me to add tests for!

github-actions · 2025-02-22T19:24:44Z

`ruff-ecosystem` results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

MichaReiser

Thanks for looking into this.

We may need to restructure the code more. I believe the current implementation also applies the fallback for inherited and maybe even user configurations.

We only want the fallback to apply to top-level project configurations.

crates/ruff_workspace/src/pyproject.rs

dylwil3 · 2025-02-23T14:57:50Z

We only want the fallback to apply to top-level project configurations.

Since configurations are resolved relative the to the file being checked, I just want to confirm that what you mean here is something like the below. (Maybe the implementation is not what you'd prefer, but is the logic doing what you meant?)

diff --git a/crates/ruff_workspace/src/pyproject.rs b/crates/ruff_workspace/src/pyproject.rs
index 9d9bc4199..cbc3958ab 100644
--- a/crates/ruff_workspace/src/pyproject.rs
+++ b/crates/ruff_workspace/src/pyproject.rs
@@ -152,7 +152,10 @@ pub fn find_user_settings_toml() -> Option<PathBuf> {
 }
 
 /// Load `Options` from a `pyproject.toml` or `ruff.toml` file.
-pub(super) fn load_options<P: AsRef<Path>>(path: P) -> Result<Options> {
+pub(super) fn load_options<P: AsRef<Path>>(
+    path: P,
+    version_strategy: TargetVersionStrategy,
+) -> Result<Options> {
     if path.as_ref().ends_with("pyproject.toml") {
         let pyproject = parse_pyproject_toml(&path)?;
         let mut ruff = pyproject
@@ -172,16 +175,21 @@ pub(super) fn load_options<P: AsRef<Path>>(path: P) -> Result<Options> {
         if let Ok(ref mut ruff) = ruff {
             if ruff.target_version.is_none() {
                 debug!("No `target-version` found in `ruff.toml`");
-                if let Some(dir) = path.as_ref().parent() {
-                    let fallback = get_fallback_target_version(dir);
-                    if fallback.is_some() {
-                        debug!(
+                match version_strategy {
+                    TargetVersionStrategy::Standard => {}
+                    TargetVersionStrategy::RequiresPythonFallback => {
+                        if let Some(dir) = path.as_ref().parent() {
+                            let fallback = get_fallback_target_version(dir);
+                            if fallback.is_some() {
+                                debug!(
                             "Deriving `target-version` from `requires-python` in `pyproject.toml`"
                         );
-                    } else {
-                        debug!("No `pyproject.toml` with `requires-python` in same directory; `target-version` unspecified");
+                            } else {
+                                debug!("No `pyproject.toml` with `requires-python` in same directory; `target-version` unspecified");
+                            }
+                            ruff.target_version = fallback;
+                        }
                     }
-                    ruff.target_version = fallback;
                 }
             }
         }
@@ -236,6 +244,13 @@ fn get_minimum_supported_version(requires_version: &VersionSpecifiers) -> Option
     PythonVersion::iter().find(|version| Version::from(*version) == minimum_version)
 }
 
+#[derive(Debug, Default)]
+pub(super) enum TargetVersionStrategy {
+    #[default]
+    Standard,
+    RequiresPythonFallback,
+}
+
 #[cfg(test)]
 mod tests {
     use std::fs;
diff --git a/crates/ruff_workspace/src/resolver.rs b/crates/ruff_workspace/src/resolver.rs
index f550f810f..ef10119c3 100644
--- a/crates/ruff_workspace/src/resolver.rs
+++ b/crates/ruff_workspace/src/resolver.rs
@@ -23,7 +23,7 @@ use ruff_linter::package::PackageRoot;
 use ruff_linter::packaging::is_package;
 
 use crate::configuration::Configuration;
-use crate::pyproject::settings_toml;
+use crate::pyproject::{settings_toml, TargetVersionStrategy};
 use crate::settings::Settings;
 use crate::{pyproject, FileResolverSettings};
 
@@ -319,7 +319,15 @@ pub fn resolve_configuration(
         }
 
         // Resolve the current path.
-        let options = pyproject::load_options(&path).with_context(|| {
+        let version_strategy = if configurations.is_empty() {
+            TargetVersionStrategy::RequiresPythonFallback
+        } else {
+            // For inherited configurations, we do not attempt to
+            // fill missing `target-version` with `requires-python`
+            // from a nearby `pyproject.toml`
+            TargetVersionStrategy::Standard
+        };
+        let options = pyproject::load_options(&path, version_strategy).with_context(|| {
             if configurations.is_empty() {
                 format!(
                     "Failed to load configuration `{path}`",

MichaReiser · 2025-02-23T15:14:46Z

Uhm, hard to say because I'm mostly unfamiliar with this part of Ruff.

Different strategies could be a solution or we start using different methods based on what configuration we're resolving (I think that's what we do in Red Knot)

dylwil3 · 2025-02-23T15:29:11Z

I guess what I'm trying to say is: what do you mean by "project root"? It doesn't seem to me like that's really a first-class notion in Ruff in the same way that it kind of has to be in uv or Red Knot, as far as I can tell.

Probably I'm just not understanding the design spec here - sorry! So far I think I understand these requirements:

(from the issue) If we can't find any configuration but there's a pyproject.toml without a tool.ruff section, don't ignore it and instead use the requires-python from there
(from the issue) If we find a ruff.toml without a target-version, fallback to the pyproject.toml's requires-python at the same level (if there's any).
Do not use the fallback when resolving user-level configuration

But I'm not understanding the requirement around the project root. Would it be possible to give an example of the behavior you're looking for?

MichaReiser · 2025-02-23T15:38:22Z

That's a good point and using the term project root was probably more confusing than helpful (because Ruff doesn't know that concept).

What I meant is that this fallback shouldn't apply to user-level configurations or an extended (extend = "dont_fallback_to_pyproject_toml_here.toml") configuration.

dylwil3 · 2025-02-23T15:41:44Z

Excellent, thank you for clarifying! That's what I suspected (and is handled by the diff above). I'll tackle the user-config and inherited config adjustments now. Sorry for the confusion!

dylwil3 · 2025-02-23T18:02:13Z

@dhruvmanila no urgency here, but before we add this to v0.10 it'd be great if you could double-check that the changes to ruff server make sense. The hope is that the changes will ensure that the settings will be resolved the same way whether you are running the server or passing in paths on the command line.

crates/ruff_workspace/src/resolver.rs

crates/ruff/tests/lint.rs

crates/ruff_workspace/src/pyproject.rs

crates/ruff_workspace/src/resolver.rs

crates/ruff_workspace/src/pyproject.rs

crates/ruff_workspace/src/resolver.rs

crates/ruff/src/resolve.rs

dhruvmanila · 2025-02-24T10:31:04Z

@dhruvmanila no urgency here, but before we add this to v0.10 it'd be great if you could double-check that the changes to ruff server make sense. The hope is that the changes will ensure that the settings will be resolved the same way whether you are running the server or passing in paths on the command line.

Yeah, I think it makes sense although I'd also test it out in an editor context. I can add it to my todo but I was wondering if you had done any testing in an editor (VS Code or any other)?

crates/ruff/src/resolve.rs

MichaReiser · 2025-02-24T09:25:38Z

crates/ruff/src/resolve.rs

+        }
+        config.target_version = fallback.map(Into::into);
+    }
    let settings = config.into_settings(&path_dedot::CWD)?;


Can we extract the path into a variable and use it both in find_fallback_target_version and when calling into_settings. It required me few cycles to understand whether path_dedot::CWD is correct but I then noticed that it's already what into_setting uses

I'm not sure, it depends on what behavior we want.

The way I have it currently set up I'm trying to make the behavior change as little as possible, so I've kept the settings resolution path the same no matter what, but attempted to find a fallback version using the same logic as we did when searching for a user configuration file. That logic would start from the stdin filename directory if it was passed in.

In other words, I don't think I can extract a path variable here since I may be passing a different value to find_fallback_target_version than I am to into_settings.

crates/ruff/src/resolve.rs

crates/ruff_workspace/src/pyproject.rs

MichaReiser · 2025-02-24T10:26:08Z

crates/ruff_workspace/src/pyproject.rs

+                            "Deriving `target-version` from `requires-python` in `pyproject.toml`"
+                        );


Suggested change

"Deriving `target-version` from `requires-python` in `pyproject.toml`"

);

"Deriving `target-version` from `requires-python` in `pyproject.toml`"

);

instead I made the spacing match the debug call in the other branch: ffd2dbf

crates/ruff_workspace/src/pyproject.rs

crates/ruff_workspace/src/resolver.rs

MichaReiser · 2025-02-24T11:19:47Z

crates/ruff_workspace/src/resolver.rs

            if let Some(pyproject) = settings_toml(ancestor)? {
                let (root, settings) =
-                    resolve_scoped_settings(&pyproject, Relativity::Parent, transformer)?;
+                    resolve_scoped_settings(&pyproject, Relativity::Parent, transformer, None)?;


It's not clear to me why using None here is correct (or when using None is correct in general). Can you tell me a bit more about it?

tried to clarify here (replacing None with new variant Unknown which signals that the configuration origin is unknown to the caller: af82f19

dylwil3 · 2025-02-28T23:38:29Z

@dhruvmanila no urgency here, but before we add this to v0.10 it'd be great if you could double-check that the changes to ruff server make sense. The hope is that the changes will ensure that the settings will be resolved the same way whether you are running the server or passing in paths on the command line.

Yeah, I think it makes sense although I'd also test it out in an editor context. I can add it to my todo but I was wondering if you had done any testing in an editor (VS Code or any other)?

I haven't tried it in an editor yet but I will!

crates/ruff/src/resolve.rs

crates/ruff/tests/lint.rs

crates/ruff_workspace/src/pyproject.rs

MichaReiser · 2025-03-10T14:25:10Z

@dylwil3 feel free to merge this into the ruff-0.10 feature branch once it's ready (I already changed the base)

dhruvmanila

The changes all look correct to me for the server settings.

Edit: Wait, I'm seeing some discrepancies in the editor context.

dhruvmanila · 2025-03-12T04:39:38Z

I'm currently testing out this in an editor context using some of the test cases mentioned in https://github.com/astral-sh/ruff/blob/8aa8c56cad2697c0e4c6a86aa997221e842dcfea/crates/ruff/tests/lint.rs

ruff/crates/ruff/tests/lint.rs

Lines 2088 to 2094 in 8aa8c56

    
           /// ``` 
        
           /// tmp 
        
           /// ├── pyproject.toml #<--- no `[tool.ruff]` 
        
           /// └── test.py 
        
           /// ``` 
        
           #[test] 
        
           fn requires_python_no_tool() -> Result<()> {

For this test case, the target version in the editor is still giving me 3.9. As per the test case, it should be 3.11 ? The debug information gives me that the indexed configuration file is empty even though the project has a pyproject.toml file (without tool.ruff heading). I think this is because the server uses the settings_toml function that skips the pyproject.toml file without a tool.ruff heading:

ruff/crates/ruff_workspace/src/pyproject.rs

Lines 81 to 85 in ba44e9d

    
           let pyproject_toml = path.as_ref().join("pyproject.toml"); 
        
           if pyproject_toml.is_file() && ruff_enabled(&pyproject_toml)? { 
        
               return Ok(Some(pyproject_toml)); 
        
           }

I believe this isn't expected? Sorry for taking this on at the last moment before the 0.10 release.

ruff/crates/ruff/tests/lint.rs

Lines 2716 to 2724 in 8aa8c56

    
           /// ``` 
        
           /// tmp 
        
           /// ├── foo 
        
           /// │   ├── pyproject.toml #<-- no [tool.ruff], no `requires-python` 
        
           /// │   └── test.py 
        
           /// └── pyproject.toml #<-- no [tool.ruff], has `requires-python` 
        
           /// ``` 
        
           #[test] 
        
           fn requires_python_pyproject_toml_above() -> Result<()> {

For this test case, I'm seeing the incorrect behavior where the target version is still 3.9.

ruff/crates/ruff/tests/lint.rs

Lines 2397 to 2404 in 8aa8c56

    
           /// ``` 
        
           /// tmp 
        
           /// ├── pyproject.toml #<-- no [tool.ruff] 
        
           /// ├── ruff.toml #<-- no `target-version` 
        
           /// └── test.py 
        
           /// ``` 
        
           #[test] 
        
           fn requires_python_ruff_toml_no_target_fallback() -> Result<()> {

For this test case, I'm seeing the correct behavior where the target version is 3.11.

dylwil3 · 2025-03-12T13:13:06Z

Update: It looks like the case where there's no ruff.toml or [tool.ruff] in any pyproject.toml (but there is a requires-python) is still not working as expected for the server. I believe it's because the logic here for the "fallback to default in the absence of any config files" case was not reproduced in the server:

ruff/crates/ruff/src/resolve.rs

Lines 104 to 115 in b098255

    
           debug!("Using Ruff default settings"); 
        
           let mut config = config_arguments.transform(Configuration::default()); 
        
           if config.target_version.is_none() { 
        
               // If we have arrived here we know that there was no `pyproject.toml` 
        
               // containing a `[tool.ruff]` section found in an ancestral directory. 
        
               // (This is an implicit requirement in the function 
        
               // `pyproject::find_settings_toml`.) 
        
               // However, there may be a `pyproject.toml` with a `requires-python` 
        
               // specified, and that is what we look for in this step. 
        
               let fallback = find_fallback_target_version( 
        
                   stdin_filename 
        
                       .as_ref()

Looking into it now - sorry for all the last minute hullabaloo close to the release!

dylwil3 · 2025-03-12T15:28:34Z

I believe the server behavior is now fixed! 🤞 I wish there were a way to write tests for it, but I tried out the failing examples in VSCode and printed the configs and they work now.

dhruvmanila · 2025-03-12T16:50:25Z

crates/ruff_server/src/session/index/ruff_settings.rs

-                    Ok(None) => {}
+                    Ok(None) => {
+                        let settings = RuffSettings::editor_only(editor_settings, &directory);
+                        index.write().unwrap().insert(directory, Arc::new(settings));
+                    }


If I'm understanding this change correctly, we'd now have a fallback settings for every directory in the project. I think this might create an unexpected behavior because for a file in a nested directory, it would use this fallback settings instead of the settings from the project root? Let me test this out.

Yeah, I tested out, I think this is an incorrect fix. Consider the following directory structure:

. ├── nested │ └── foo │ └── test.py ├── pyproject.toml └── test.py

The nested/foo/test.py does not consider any settings from pyproject.toml, it's only the test.py file that will consider it.

It's not entirely clear to me why the change here is necessary. Shouldn't the changes above be sufficient?

MichaReiser · 2025-03-12T17:06:25Z

crates/ruff_server/src/session/index/ruff_settings.rs

+        let mut config = Configuration::default();
+        if let Some(fallback_version) = find_fallback_target_version(root) {
+            config.target_version = Some(PythonVersion::from(fallback_version));
+        };
+


Does that mean that we'll pick up the requires-python constraint even if a user uses editor-only in their settings. I'd be a bit confused if editor-only loads any project settings. @dhruvmanila what's your take on this?

Yeah, I don't think we should be looking at any of the config files if the configuration preference is editorOnly unless the user has explicitly asks us using the ruff.configuration.

I think we won't have gotten this far in the code in that case, though, right? We exited earlier here:

ruff/crates/ruff_server/src/session/index/ruff_settings.rs

Lines 114 to 123 in dd2313a

if editor_settings.configuration_preference == ConfigurationPreference::EditorOnly {

tracing::debug!(

"Using editor-only settings for workspace: {} (skipped indexing)",

root.display()

);

return RuffSettingsIndex {

index: BTreeMap::default(),

fallback: Arc::new(RuffSettings::editor_only(editor_settings, root)),

};

}

That branch will be calling RuffSettings::editor_only to create a default configuration so we'll be getting there in this case.

MichaReiser · 2025-03-13T09:09:03Z

crates/ruff/src/resolve.rs

+        let settings = resolve_root_settings(
+            &pyproject,
+            config_arguments,
+            ConfigurationOrigin::UserSettings,
+        )?;


It seems inconsistent that we don't apply the fallback behavior if a user only has the user-level configuration. It means that we won't pick up the right python version if you have:

a user level ruff configuration

but use a pyproject.toml without a tool.ruff section at the project level

I think it would be good to apply the requires-python fallback in this case as well.

MichaReiser · 2025-03-13T11:00:50Z

I pushed three new commits:

This is more a quality of life improvement: The server now shows logs emitted with log::debug (instead of tracing::debug)
Changes the behavior for user-level configurations: A pyproject.toml now always overrides the target-version from the user-level configuration. I'm not a 100% if this is the right change but it's what we do in Red Knot. However, Red Knot's model is slightly different so I'm not sure if this behavior makes sense for Ruff. Maybe it's best to revert it but i'm interested in feedback
The main changes on the server side

@dhruvmanila and @dylwil3 could yo uboth take a look

MichaReiser · 2025-03-13T11:05:46Z

@dylwil3 we should also update https://docs.astral.sh/ruff/configuration/#config-file-discovery or have a new section explaining the target-version discovery but we can do this in a separate PR

dhruvmanila · 2025-03-13T11:22:57Z

2. Changes the behavior for user-level configurations: A pyproject.toml now always overrides the target-version from the user-level configuration. I'm not a 100% if this is the right change but it's what we do in Red Knot. However, Red Knot's model is slightly different so I'm not sure if this behavior makes sense for Ruff. Maybe it's best to revert it but i'm interested in feedback

IIUC, between a user-level config (~/.config/ruff.toml) and the pyproject.toml in the project, Ruff will prefer to use the requires-python in the project config if present. If not, it'll use the one in the user-level config if present.

Why are you not sure about the behavior in Ruff? I think preferring a project specific version makes sense intuitively, I'd be surprised to see that the requires-python isn't being picked up by Ruff even though it's defined in the project config.

dylwil3 · 2025-03-13T11:31:03Z

I pushed three new commits:

Thank you, this looks awesome!

This is more a quality of life improvement: The server now shows logs emitted with log::debug (instead of tracing::debug)

✅

Changes the behavior for user-level configurations: A pyproject.toml now always overrides the target-version from the user-level configuration. I'm not a 100% if this is the right change but it's what we do in Red Knot. However, Red Knot's model is slightly different so I'm not sure if this behavior makes sense for Ruff. Maybe it's best to revert it but i'm interested in feedback

This seems intuitive to me.

The main changes on the server side

Tested this in VSCode and looks good! The behavior Dhruv pointed out before with a nested file no longer occurs, and the fallback matches the CLI behavior in the edge case where there is no [tool.ruff] or ruff.toml anywhere (so, in Dhruv's example, if you open VSCode from tmp you'll get a different target version than you would by opening VSCode from nested/foo).

I will work on some documentation!

MichaReiser · 2025-03-13T11:32:30Z

Okay, so I think this PR is ready to land, assuming my changes look good.

dhruvmanila · 2025-03-13T11:44:14Z

The code looks good, thank you for addressing the issues. I also did some quick testing (not the same ones as Dylan).

dylwil3 · 2025-03-13T11:49:07Z

Thanks so much @dhruvmanila and @MichaReiser !!

…ot found (#16721) ## Summary Restores #16319 after it got dropped from the 0.10 release branch :( --------- Co-authored-by: dylwil3 <[email protected]>

## Summary Follow-up release for Ruff v0.10 that now includes the following two changes that we intended to ship but slipped: * Changes to how the Python version is inferred when a `target-version` is not specified (#16319) * `blanket-noqa` (`PGH004`): Also detect blanked file-level noqa comments (and not just line level comments). ## Test plan I verified that the binary built on this branch respects the `requires-python` setting ([logs](https://www.diffchecker.com/qyJWYi6W/), left: v0.10, right: v0.11)

dylwil3 added breaking Breaking API change configuration Related to settings and configuration do-not-merge Do not merge this pull request labels Feb 22, 2025

dylwil3 added this to the v0.10 milestone Feb 22, 2025

dylwil3 force-pushed the requires-python branch 2 times, most recently from ad3eedb to 0c589b7 Compare February 22, 2025 19:58

MichaReiser reviewed Feb 23, 2025

View reviewed changes

crates/ruff_workspace/src/pyproject.rs Show resolved Hide resolved

crates/ruff_workspace/src/pyproject.rs Outdated Show resolved Hide resolved

dhruvmanila reviewed Feb 24, 2025

View reviewed changes

MichaReiser reviewed Feb 24, 2025

View reviewed changes

dhruvmanila mentioned this pull request Feb 28, 2025

ruff 0.9.8 raising error 'SyntaxError: Cannot use match statement on Python 3.9 (syntax was added in Python 3.10)' in Python 3.13 #16417

Closed

dylwil3 force-pushed the requires-python branch from 3a1033a to 38bf1bd Compare February 28, 2025 23:14

MichaReiser approved these changes Mar 3, 2025

View reviewed changes

crates/ruff/src/resolve.rs Outdated Show resolved Hide resolved

crates/ruff/tests/lint.rs Outdated Show resolved Hide resolved

crates/ruff/tests/lint.rs Show resolved Hide resolved

crates/ruff_workspace/src/pyproject.rs Outdated Show resolved Hide resolved

dylwil3 force-pushed the requires-python branch 2 times, most recently from 583edc8 to 8aa8c56 Compare March 4, 2025 13:33

dylwil3 mentioned this pull request Mar 7, 2025

B905 not being raised when "B" rules enabled #16541

Closed

MichaReiser changed the base branch from main to micha/ruff-0.10 March 10, 2025 14:24

MichaReiser removed the do-not-merge Do not merge this pull request label Mar 10, 2025

MichaReiser force-pushed the micha/ruff-0.10 branch from 44eec2b to e4e1c58 Compare March 10, 2025 14:28

dhruvmanila approved these changes Mar 12, 2025

View reviewed changes

dylwil3 added 2 commits March 12, 2025 10:13

test cli override

229e905

for server use editor config with fallback version as fallback

6093d74

dhruvmanila reviewed Mar 12, 2025

View reviewed changes

MichaReiser reviewed Mar 12, 2025

View reviewed changes

MichaReiser reviewed Mar 13, 2025

View reviewed changes

MichaReiser added 3 commits March 13, 2025 11:56

Collect logs from the log crate in the server logs

f5d0203

Use the requires-python fallback with a user-level configuration

49a593e

Align server indexing with CLI behavior

dc26d44

dylwil3 merged commit 15c0535 into astral-sh:micha/ruff-0.10 Mar 13, 2025
20 of 21 checks passed

MichaReiser mentioned this pull request Mar 13, 2025

Ruff 0.10 #16600

Merged

2 tasks

BrewTestBot mentioned this pull request Mar 13, 2025

ruff 0.10.0 Homebrew/homebrew-core#210848

Merged

MichaReiser mentioned this pull request Mar 14, 2025

Fallback to requires-python in certain cases when target-version is not found #16721

Merged

MichaReiser mentioned this pull request Mar 14, 2025

Ruff 0.11.0 #16723

Merged

BrewTestBot mentioned this pull request Mar 14, 2025

ruff 0.11.0 Homebrew/homebrew-core#210913

Merged

Avasam mentioned this pull request Mar 17, 2025

FA102 errors eventhough requires-python in pyproject.toml is ">=3.12" #10299

Closed

QuantumGhost mentioned this pull request Mar 17, 2025

pre-commit script wrongly report SyntaxError for match statement langgenius/dify#15987

Closed

5 tasks

Avasam mentioned this pull request Mar 18, 2025

ruff.toml has dependency on extant pyproject.toml jaraco/skeleton#155

Closed

ntBre mentioned this pull request Dec 12, 2025

Unexpected behavior when using extend and target-version #21956

Closed

dylwil3 mentioned this pull request Jan 12, 2026

fix: target-version fallback with extend #21980

Merged

		"Deriving `target-version` from `requires-python` in `pyproject.toml`"
		);

	if editor_settings.configuration_preference == ConfigurationPreference::EditorOnly {
	tracing::debug!(
	"Using editor-only settings for workspace: {} (skipped indexing)",
	root.display()
	);
	return RuffSettingsIndex {
	index: BTreeMap::default(),
	fallback: Arc::new(RuffSettings::editor_only(editor_settings, root)),
	};
	}

Comments

Conversation

dylwil3 commented Feb 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Implementation

Testing

Uh oh!

github-actions bot commented Feb 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ruff-ecosystem results

Linter (stable)

Linter (preview)

Formatter (stable)

Formatter (preview)

Uh oh!

MichaReiser left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

dylwil3 commented Feb 23, 2025

Uh oh!

MichaReiser commented Feb 23, 2025

Uh oh!

dylwil3 commented Feb 23, 2025

Uh oh!

MichaReiser commented Feb 23, 2025

Uh oh!

dylwil3 commented Feb 23, 2025

Uh oh!

dylwil3 commented Feb 23, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dhruvmanila commented Feb 24, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dylwil3 commented Feb 28, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MichaReiser commented Mar 10, 2025

Uh oh!

dhruvmanila left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dhruvmanila commented Mar 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dylwil3 commented Mar 12, 2025

Uh oh!

dylwil3 commented Feb 22, 2025 •

edited

Loading

github-actions bot commented Feb 22, 2025 •

edited

Loading

`ruff-ecosystem` results

dhruvmanila left a comment •

edited

Loading

dhruvmanila commented Mar 12, 2025 •

edited

Loading

MichaReiser commented Mar 13, 2025 •

edited

Loading