yamllint
yamllint copied to clipboard
use of [tool.yamllint] in a pyproject.toml
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 https://github.com/adrienverge/yamllint/issues/383
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.
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?
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.
Also, see this opinion in https://github.com/pypa/setuptools/pull/3979#pullrequestreview-1691482008 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 afterdocs/
and beforenewsfragments/
and is clearly distinct from towncrier or tox or pytest settings.
Is there any progress on it?
Is there any progress on it?
I don't think it is planned for this project.
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.
I don't think it is planned for this project.
Sad to hear that.