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

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

Open raybellwaves opened this issue 1 year ago • 8 comments

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

Apr 21 '23 20:04 raybellwaves

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.

Apr 22 '23 07:04 adrienverge

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?

Aug 23 '23 08:08 ringohoffman

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.

Aug 30 '23 07:08 adrienverge

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 after docs/ and before newsfragments/ and is clearly distinct from towncrier or tox or pytest settings.