Allow configuration to be defined on a file-scoped basis

[Czaki]

It will be nice to allow define banned-api rules per file pattern.

In general, there are API that may be useful in tests but should not be used in the library itself:
For example, warnings.catch_Warnings because of python/cpython#73858.

On the other hand, I would like to block using numpy.random in tests but allow in the library and/or examples (as it leads to random test failure).

If you think it is useful, I could try to contribute (learning rust).

[MichaReiser]

That makes sense. Have you tried using a hierarchical configuration to achieve your goal? The way this works is that you create a new ruff.toml in the test directory that extends your default configuration. The test-specific configuration can override individual settings.

[Czaki]

Unfortuantelly in this project (napari), test are not stored in a separate directory but in _test modules. And I'm only one of the maintainers.
(and this simplifies searching for a test of a given function).

[charliermarsh]

Really wishing we had ESLint-style file overrides, as in:

{
  "rules": {
    "quotes": ["error", "double"]
  },

  "overrides": [
    {
      "files": ["bin/*.js", "lib/*.js"],
      "excludedFiles": "*.test.js",
      "rules": {
        "quotes": ["error", "single"]
      }
    }
  ]
}

[Czaki]

cibuildwheel project use toml tables to implement overwrite rules inside pyproject.toml https://github.com/pypa/cibuildwheel/
https://cibuildwheel.readthedocs.io/en/stable/options/#overrides

Maybe it could be an inspiration?

[MichaReiser]

Really wishing we had ESLint-style file overrides, as in:

{
  "rules": {
    "quotes": ["error", "double"]
  },

  "overrides": [
    {
      "files": ["bin/*.js", "lib/*.js"],
      "excludedFiles": "*.test.js",
      "rules": {
        "quotes": ["error", "single"]
      }
    }
  ]
}

I've mixed feelings about overrides. It is powerful but can become confusing if you mix it with extend. E.g. what happens if you have:

{
   "rules": {
     "quotes": ["error", "double"]
   },
 
   "overrides": [
     {
       "files": ["bin/*.js", "lib/*.js"],
       "excludedFiles": "*.test.js",
       "rules": {
         "quotes": ["error", "single"]
       }
     }
   ]
}

and

{
	"extend": "config-above.json",
   "rules": {
     "quotes": ["error", "double"]
   }
}

What does now bind stronger, the parent configuration because it's in the overrides section or the extend? I think we would need to change our configuration more drastically to make "overrides" feel intuitive, similar to what eslint does with the new flat configuration

[charliermarsh]

(Making this issue more general -- it would be nice to support something like ESLint's flat configuration, in which you can define configuration that only applies to a subset of files.)

[DetachHead]

i'm fine with hierarchical configuration, but the only problem is that i wish it would inherit the flake8-tidy-imports.banned-api options from parent directories:

# ./pyproject.toml
[tool.ruff.flake8-tidy-imports.banned-api]
"foo".msg = "banned project-wide"

# ./tests/ruff.toml
extend = "../pyproject.toml"

[flake8-tidy-imports.banned-api]
"bar".msg = "only banned in tests"

# tests/test_foo.py
import foo # no error, because the `banned-api` the `tests` directory doesn't inherit from the global one

[BT-rmartin]

In my case #7890 we want to configure isort on file-scope basis, and in our particular need the hierarchical solution is not feasible, as we want it for every init.py file. Is there any progress on this topic @charliermarsh ?