use of [tool.yamllint] in a pyproject.toml

[raybellwaves]

Curious if there are some examples of using yamllint with a pyproject.toml file (i.e. not need a .yamllint.yaml config file).

If so i'm also curious how one passes the rules to pre-commit without a .yamllint.yaml config file

Edit: may be a dup of #383

[adrienverge]

Hello, it's an interesting question.

Yamllint is written in Python, but as a tool it's language-independent. In theory it could try to read config from many environments, e.g. pyproject.toml or setup.cfg for Python projects, package.json for JavaScript projects, Cargo.toml for Rust projects... and Coala, MegaLinter, pre-commit, Prettier (.prettierrc), .vimrc, EditorConfig, etc. I agree it would be a nice-to-have addition for some users, however like for many nice-to-have add-ons, it would be a burden for the project, so I'm not sure it's worth.

Related: #505, #383.

[ringohoffman]

I don't think this is an arbitrary thing to support. PEP 518, the spec for pyproject.toml, specifically has a section describing the tool table, "where any tool related to your Python project, not just build tools, can have users specify configuration data".

tomlsort (which I see as being similar to this project), black, isort, pylint, ruff, mypy, and pyright all support the pyproject.toml tool table in addition to their own proprietary config files.

I think using tomli in Python < 3.11 and tomllib afterwards, we should be able to parse the tool.yamllint section of a pyproject.toml into the same data structure that .yamllint.yml is parsed into in the case that no .yamllint.yml file is found.

What do you think about this, @adrienverge?

[adrienverge]

Hello,

I agree that PEP 518 allows to put configuration inside pyproject.toml, no question about that.
All the tools you reference are 100% Python-specific (black, isort, pylint, ruff, mypy, pyright) or tightly bound to the Python ecosystem (toml-sort). On the opposite, yamllint is language-independent and aims to be used on any project, in any language. Users shouldn't even know that it's written in Python.

I'm not favorable to reading configuration from pyproject.toml because:

• There would be no reason not to support other project-metadata files: package.json for JavaScript projects, Cargo.toml for Rust projects... and Coala, MegaLinter, pre-commit, Prettier (.prettierrc), .vimrc, EditorConfig, etc.
• Reading and merging configurations from pyproject.toml (TOML format) and .yamllint (YAML format) and option -d (YAML format) would be a mess, especially when overriding complex configuration options.
• Debugging a misconfiguration would become much harder.

[DimitriPapadopoulos]

Also, see this opinion in pypa/setuptools#3979 (review) against stockpiling everything in pyproject.toml:

I do wish to retain the mypy settings in mypy.ini for two reasons:

• The skeleton for this project is maintained upstream, which defines the mypy settings in its own file. Moving the settings to a different file makes it difficult to compare and manage the differences with settings inherited from upstream.
• Piling all project settings in pyproject.toml is a bad idea in general. I've been meaning to write a blog post about it, but the tl;dr is that because there's no ordering or namespacing, the settings lack structure and consistency (compared with mypy which always appears after docs/ and before newsfragments/ and is clearly distinct from towncrier or tox or pytest settings.

[hasansezertasan]

Is there any progress on it?

[ringohoffman]

Is there any progress on it?

I don't think it is planned for this project.

[silverwind]

I support this because it allows me to get rid of a config file.

I've seen other non-python linters like djlint use pyproject.toml, so I think it's totally fine to use it for non-python purposes.

[hasansezertasan]

I don't think it is planned for this project.

Sad to hear that.