Document "black-compatible" configs for common linters/fixers

This is a documentation feature-request.

Commonly when bootstrapping a new project, my personal preferred config is (among other things): flake8, isort, black The trouble is, every time I do this, I end up copy-pasting around the same config data so that flake8 and isort behave in a “black-compatible” way.

I also see issues when I occasionally run pylint on things because I don’t personally use it often enough to have black-compatible config on-hand.

If black documented, in one place, config for commonly-used tools, I think that would be great. You can dig this info out of the “The Black code style” page for flake8, isort, but

1. The information is kind of buried in there
2. It’s not clear where to suggest additional config for other common tools

A while back, I reached out to flake8 to ask about adding “black-compatible” mode as config there, which is sort of pushing the responsibility for compatibility in the other direction. That feature request was rejected – and I think the grounds for turning it down were reasonable.

But the thing I wanted there is still basically the same: I’m a user of several popular linters and fixers. I don’t want, as a user, to be solely responsible for keeping these various tools compatible with one another. I want the projects to own this, and to be a consumer of that consolidated wisdom.

Fancy things – like an option to generate config – would be lovely, but that’s not even necessary. Just having a single place to find docs which write down something like this would be great

setup.cfg

[isort]
multi_line_output = 3
include_trailing_comma = true
force_grid_wrap = 0
combine_as_imports = true
line_length = 88

[flake8]
max-line-length = 88
extend-ignore = W503,W504

[pylint]
# some stuff goes here, ignoring rules which break on black'd code

[common-tool-X-which-I'm-forgetting]
# more config

pyproject.toml

# compatible pyproject.toml content...

I’m happy to write the content myself, to the best of my ability, perhaps as a new docs page. But it doesn’t seem worth doing unless it’s actually wanted here.

[sirosen]

Since it sounds like this would be a welcome addition, I’ll try to take a crack at this during some of my upcoming time off of work.

My inclination is to make this a new docs page, and try to replace the readme and docs content with links to the new content. Feel free to tell me to do it some other way though.

[sirosen]

I was playing with this and I believe that all you need for .pylintrc is, indeed, disable=format.

It’s hard to know for sure without a systematic review of every pylint rule, but based on what limited testing I’ve carried out (e.g. diffing pylint --disable=format runs before and after applying black), that seems right. Occasionally other rules will get tripped like “similarity” simply because that’s how the cookie crumbles, but it’s not the sort of thing which is a conflict between the tools.