astral-sh / ruff

An extremely fast Python linter and code formatter, written in Rust.

Home Page:https://docs.astral.sh/ruff

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ruff config custom filename

padrepitufo opened this issue · comments

When using the --config option in .pre-commit-config.yaml like so:

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.4.3
    hooks:
      - id: ruff
        name: pycln api
        files: ^api/
        args: ["--config=./pyproject.ruff.toml"]

or when running the command locally with:

ruff --config pyproject.ruff.toml

and supplying a pyproject formatted file with a name other than pyproject.toml (as shown above), ruff will not recognize the file as a pyproject formatted file (it will assume it is a malformed .ruff.toml file) and give errors like so:

  Cause: TOML parse error at line 1, column 1
  |
1 | [tool.ruff]
  | ^
unknown field `tool`

Use Case

Why oh why am I splitting up my pyproject.toml files? The team I'm working with generally does this when the section gets long within pyproject.toml. While it is nice to keep all the configurations in one file, it is also nice to keep all configurations in the same format and that is what I'm aiming for.

Is this something that could be supported by the ruff community?

Context

command: ruff --config pyproject.ruff.toml
ruff: v0.4.3
pre-commit: 3.7.0

Is this conformant to the pyproject.toml specification? (I think probably not?) Why not just use the ruff.toml syntax?

@zanieb its a great question - I've been looking to see if there is somewhere in the spec that specifies that the name must be pyproject.toml or that it is just convention. The pattern in use does work with other tools; however, it's possible that it only happens to work because they aren't enforcing the aforementioned potentially existing spec.

The main reason for not adopting ruff.toml syntax is to keep these config files in the same format -- pyproject.toml format.

the closest I'm finding is where the name is required when declaring build system dependencies. Does that mean it is not required in other cases?

I'm not strongly opposed to looking for a [tool.ruff] top-level section in a ruff.toml but I don't know if this case is particularly motivating — it adds complexity for other users and the implementation. We support the same configuration, it's just a matter of being present in the top-level or a nested section.

The name is defined in PEP 518, but there's not much else about it afaik.

Yeah, pyproject.toml is special and I don't think we should try to parse other TOML files as if they are pyproject.toml. It's helpful in this specific case, but it would make it harder to give good error messages and break other assumptions.

Going to close for now -- I suggest using ruff.toml here or naming the file pyproject.toml.