black and isort conflict unless line length copy/pasta

[Akuli]

pyproject.toml:

[tool.black]
line-length = 100
skip-magic-trailing-comma = true
skip-string-normalization = true

[tool.isort]
#line_length = 100   # Uncomment to fix
profile = "black"
multi_line_output = 3

isort wants:

from typing import (
    TYPE_CHECKING,
    Any,
    Callable,
    Iterator,
    List,
    Optional,
    Tuple,
    overload,
)

black wants:

from typing import TYPE_CHECKING, Any, Callable, Iterator, List, Optional, Tuple, overload

You can copy/paste the same line length to both configs but it would be nice if profile = "black" would read it from black's config. Or is that not how profiles work?

[timothycrosley]

Hi @Akuli,

I could see why you would want this! However, I think simply setting them for both is the better option. The profile will give you the same default as black's so you only have to do this, if you want a custom line length. isort can't reasonably find all locations of blacks configuration parameters now and to the future. Doing some level of magic pulling it in I feel like would set up the project and users for confusing issues, as it would sometimes pick it up and sometimes not, and even worse could lead to weird environment dependent issues that break in CI but work locally or vice versa.

[Akuli]

I agree that this may be too fragile to actually implement, but in practice, using black's configuration isn't quite that difficult. If someone has isort configuration in pyproject.toml, then they very likely configure black in pyproject.toml as well. If we never touch any other black config files, then I don't really see how exactly it could "break in CI but work locally or vice versa".

[timothycrosley]

Right, but that's only one possible way someone could have that implemented. They could instead:

• Have parameters passed to the black command line (in script invocation, or in precommit call)
• Use black as a library, with a line length override (ala white - prepackaged scripts like this, make this a surprisingly common thing)
• Have isort in it's own multiple configs for a directory, with one pyproject.toml for black at the top, so the connection becomes unclear.
• Have blacks config in a random shared (or not shared, but just separate) location, passing --config to any invocations.

And those are just a few of the complications I can think of off the top of my head with just the current implementation of black. Who knows what could happen in the future! It's much better for the project to require a very small duplication to set the line length combination, than to try to be magical here, with a ton of asterisks that both us and users need to think about IMHO.

"break in CI but work locally or vice versa".

Some projects move around configs or create them dynamically either in (usually) the CI or sometimes the local step. People don't tend to assume that applications are cross reading configs, so when one application does start doing that, it can cause breakages.

One example of what this could look like:

A project uses pre-commit for local usage (and sets the line length manually in the command invocation).
In CI, they copy or merge a common pyproject.toml template (for all projects they manage) at the root of repo invocation.

Now all the sudden isort has the "wrong" line-length when ran locally (because it can't read from precommit command invocation in any sustainable way), but correct when ran from CI. These kind of things cause a ton of pain both for users and the project because they can be hard to track down and explain. And often times the people who set up the weird setup are not the users of the tool that are then trying to understand why it's not working consistently.

[Akuli]

A long wall of text. I didn't read it, but I'm convinced!