Giters

PyCQA / flake8

flake8 is a python tool that glues together pycodestyle, pyflakes, mccabe, and third-party plugins to check the style and quality of some python code.

Home Page:https://flake8.pycqa.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Options for moving forward re: pyproject.toml

Diggsey opened this issue · comments

commented

I read through #234 for context on this. Unfortunately the links were broken due to the move from gitlab, but from what I gathered, the following were things considered blockers for adding support for pyproject:

  1. pip to change its behaviour so mere presence of the file does not change functionality
    this probably involves a PEP, or at least a discussion on the various pypa mailing lists
  2. python to consider adding a standard library toml implementation
    neither toml (the configration language) nor the python implementations (most popular being toml, tomlkit, pytoml afaik) on pypi are even 1.0 so I don't see this happening any time soon

the first one is a hard blocker for me accepting this as it imposes technical limitations on users which are outside of the control of this project.

This only makes sense assuming these additional unwritten constraints:

  1. The code path which flake8 uses to read configuration is not made more complicated (ie. if pyproject.toml is added, the older options must go).

  2. Projects which are broken by PEP517 can continue to use flake8.

Since the original issue was opened, usage of pyproject.toml has only become more widespread, and the benefits of tools like poetry are so great, that I don't see it going away any time soon.

It also seems like blocker (1) is unlikely to ever be lifted. The choice then is:
a) Never support pyproject.toml in flake8.
b) Find a way to bypass blocker (1) by finding another way to remove the downsides.

As a result, I would like to propose some solutions for consideration, which I believe can avoid the downsides. For options which are backwards incompatible, the assumption is that they would happen in a new major release:

  • Do what black does.
    There is only a single toml configuration parser, and pyproject.toml is read by default, but the file to use can be overridden on the command-line, eg. black --config notpyproject.toml. Projects which cannot use pyproject.toml can use this option.

  • Open a path for simplifying the configuration code path.
    At the end of the day, reading configuration from potentially multiple sources should not be that complicated. If adding an additional source of configuration would complicate the existing code too much, then perhaps a way forward would be for people interested in adding pyproject.toml support, to first help to simplify the existing code such that a new config file is less of a burden to maintain.

Regarding the need for a TOML library: black, coverage, etc. seem to use tomli, which appears to be very lightweight, well tested, and is 1.x. If necessary, it could be an optional dependency, only imported if a pyproject.toml is found.