Additional configuration file .ruff.toml

[s0undt3ch]

First of all, Thank You for this blazing fast tool!
I must also say that some of my smaller projects(because it will be easier and faster) will get migrated to ruff pretty soon.

There are however a few big projects which it will not be that easy to fix in one batch.
They even have parts where the rules are not the same.
The good news is, while they are not in a monorepo, ruff's monorepo support and configuration extending by means of additional pyproject.toml and ruff.toml will simplify this.
We will not be using additional pyproject.toml files since, as I mentioned, they are big, but non monorepo, projects.
That leaves us with ruff.toml.
However, I feel like a .ruff.toml would be something that would immediately "say", this is a local configuration file as opposed to something that the project requires to make it work.

Would it be possible to, additionally, check for, and support, .ruff.toml configuration files?

[not-my-profile]

We will not be using additional pyproject.toml files since, as I mentioned, they are big, but non monorepo, projects.

I don't understand this at all. What is the problem with using pyproject.toml files?

[s0undt3ch]

I don't understand this at all. What is the problem with using pyproject.toml files?

We use pyproject.toml at the root of the repo.
When I say we won't use it, I'm referring to directories within the repo, it'll be confusing since pyproject.toml is used to configure a project. Having more than one suggests more projects, and thus a monorepo layout, which is not the case.

[charliermarsh]

Ah yeah, ruff.toml is designed for this purpose. So the question is whether we'd support .ruff.toml -- which wouldn't change semantics at all, right? Just the nomenclature?

My initial reaction is that I'd rather not support multiple file names... and yet, ESLint does expect everything except package.json to be dot-prefixed: https://eslint.org/docs/latest/use/configure/configuration-files#configuration-file-formats. So there's definitely precedent.

[s0undt3ch]

ruff.toml and .ruff.toml would do and behave the exact same way.
It's just a matter of making it "less" visible if there's a need to have a few of them on the repository.

[charliermarsh]

Yeah totally understand. Lemme think on it for a bit! It's a reasonable request.

[s0undt3ch]

For additional context on why we would need multiple config files, we have some rules we apply to our application code, and the rules for tests are a bit more relaxed.

[s0undt3ch]

Yeah totally understand. Lemme think on it for a bit! It's a reasonable request.

Thank You.

[KyleKing]

I personally would use .ruff.toml, if available. Other major Python tools support: .flake8, .mypy.ini, .pylintrc, etc.

For additional context on why we would need multiple config files, we have some rules we apply to our application code, and the rules for tests are a bit more relaxed.

I don't know if you have considered it, but you may want to try per-file-ignores rather than multiple configuration files. This is from one of my projects:

[per-file-ignores]
'*tests/*.py' = [
    'ANN201',  # Missing return type annotation for public function
    'S101',    # Matches 'assert'
]

[s0undt3ch]

I don't know if you have considered it, but you may want to try per-file-ignores rather than multiple configuration files.

Just started testing the tool.
Didn't know it supported globs. Good to know.

[charliermarsh]

Yeah per-file-ignores is the recommended route for sub-package configuration if all you need to do is turn rules off (which is common for tests).