Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Read configuration from setup.cfg and tox.ini?

See original GitHub issue

gitlint can read configuration options from .gitlint. Is it possible add feature for reading options from setup.cfg and tox.ini?

For example flake8 can read configuration options from .flake8, setup.cfg, or tox.ini files. It is very convenient

Issue Analytics

State:
Created 5 years ago
Reactions:4
Comments:6 (5 by maintainers)

Top GitHub Comments

2reactions

sigmavirus24commented, Nov 23, 2022

Personally, gitlint isn’t a project specific to python. To the best of my knowledge people use it who aren’t using it on python projects. Switching to TOML might be nice but it’s not as common as a format as would be nice if we’re supporting a new format. Further supporting pyproject.toml only helps python projects, not anyone else. It then introduces a filename as an option that makes no sense to anyone outside the python community. I’m not fond of that, personally. Gitlint is written in python but it’s not just for python people

1reaction

jorisrooverscommented, Nov 22, 2022

I have changed my mind on this and mostly agree with @webknjaz’s and @sigmavirus24 assessment at this point.

Supporting extra formats is a lot of maintenance overhead that I’m not willing to take on right now and it indeed can cause some complexity on the user side as well.

Having said that, with the pervasiveness of pyproject.toml these days, I have had some second thoughts about #115 and whether longer term we should consider supporting it. I know for gitlint itself I’m considering moving to pyproject.toml entirely (or as much as possible). To be clear: I mean only supporting pyproject.toml in addition to .gitlint(.ini). No support for tox.ini or setup.cfg as per the reasons stated.

I think the preference of having everything sit in pyproject.toml or keep them all in separate config files is exactly that: preference. I can see that the occasional python developer or small project maintainer might be more inclined towards the single file for everything approach to declutter the project root - it’s definitely something that speaks to me. For multi-project maintainers with more standardized and automated setups, I can relate to @webknjaz’s arguments. I’ve worn both hats and again, think it’s mostly about preference and context.