Feature: pyproject.toml support for configuration

[wakemaster39]

With PEP518 and pyproject.toml becoming a standard way of configuring tools I was wondering it if it something that would be considered to be supported? I am happy to see if I can make the changes necessary. I wanted to get confirmation it is something that would be accepted before I put in the effort.

[sigmavirus24]

gitlint is a tool that can be used outside of the python community. Having to support only 1 configuration file (.gitlint) makes things easier to maintain and far less confusing for users

[jorisroovers]

Thanks for your interest :-)

I agree with @sigmavirus24 on this (both from usability and maintenance perspectives).

We already have a similar request in #82, which I've left open since tox.ini and setup.cfg are ini files, i.e. the same as the existing gitlint configuration format. I don't think I'll get around to doing that soon though (and I haven't really investigated, there might be incompatibilities).

There's a few times I've wished I had picked something else than ini to better support complex types such as dictionaries and lists, but I don't want cause friction for end-users by switching formats at this point. The main reason I had picked ini is because that's what tools such as pylint and flake8 used at the time (just learned that pylint does support pyproject.toml now as well). And as pointed out, supporting multiple formats causes maintenance overhead that I prefer not to take on right now.

[jorisroovers]

I won't be doing this as of now, for the aforementioned reasons. Closing this issue.

[Freed-Wu]

gitlint is a tool that can be used outside of the python community.

An example is a codespell, which is a spell check written by python, is also a tool that can be used outside of the python community. They have added support to pyproject.toml and still keep support for .codespellrc and setup.cfg for compaiability.

Having to support only 1 configuration file (.gitlint) makes things easier to maintain and far less confusing for users

I agree easier to maintain. However, if it don't support any configuration file, it will be eaier. So is its configuration redundant? I don't think so. In some aspects, user's experience is more important. Consider two situations:

One: every tool has its configuration. codespell use .codespellrc, gitlint use .gitlint, etc.

Two: flake8 can use [tool.flake8] in pyproject.toml, codespell can use [tool.codespell] in pyproject.toml, gitlint can use [tool.gitlint], etc.

Which is more confusing for users? Which is more convenient for users? Why not let user simply use one pyproject.toml to do all work. Not face all different configuration files, which content maybe json (addon-info.json), yaml (.yamllint.yml), toml (pyproject.toml), dosini (.gitlint). As an user, I think learning one language (toml) is less confusing than learning four lanugages (json, yaml, toml, dosini). Now PEP518 has directed a correct way to solve this problem. Why we don't do so?

So I cannot agree less confusing for users.

[sigmavirus24]

Two: flake8 use [tool.flake8]

No. No it doesn't. (I'm a maintainer of Flake8, I know.)

@Freed-Wu I can't tell if you're just trying to make an argument and you don't bother to fact check yourself, or if you're intentionally lying to make a compelling case but much of what you've been saying has been incorrect. I won't bother to check codespell to see if you're correct there because you've already lost all credibility in my perspective.

Now PEP518 has directed a correct way to solve this problem.

No, again, it provides affordances, not direction. It also doesn't bind the larger community to do anything.

[Freed-Wu]

Two: flake8 can use [tool.flake8] in pyproject.toml, codespell can use [tool.codespell] in pyproject.toml, gitlint can use [tool.gitlint], etc.

I just want to take an imaginary. In fact, gitlint use [tool.gitlint] is also incorrect. To avoid misunderstanding, I have added can to the original sentence.

I won't bother to check codespell to see if you're correct

See https://github.com/codespell-project/codespell#using-a-config-file (In fact, their support is added recently)

Using a config file
-------------------

Command line options can also be specified in a config file.

When running ``codespell``, it will check in the current directory for a file
named ``setup.cfg`` or ``.codespellrc`` (or a file specified via ``--config``),
containing an entry named ``[codespell]``. Each command line argument can
be specified in this file (without the preceding dashes), for example::

    [codespell]
    skip = *.po,*.ts,./src/3rdParty,./src/Test
    count =
    quiet-level = 3

Codespell will also check in the current directory for a ``pyproject.toml``
(or a path can be specified via ``--toml <filename>``) file, and the
``[tool.codespell]`` entry will be used as long as the tomli_ package
is installed, for example::

    [tool.codespell]
    skip = '*.po,*.ts,./src/3rdParty,./src/Test'
    count = ''
    quiet-level = 3

These are both equivalent to running::

    codespell --quiet-level 3 --count --skip "*.po,*.ts,./src/3rdParty,./src/Test"

I'm a maintainer of Flake8

As a conclusion, it depends on you.

I can't tell if you're just

Depends on you, too.

it provides affordances, not direction

OK.

I have no intention to offend you. Now let us end up this discussion.