black: Latest release of Black does not respect [--config .pyproject.toml] setting in pre-commit

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

Checkout latest “Apache/Airflow” sources https://github.com/apache/airflow/
Run pre-commit install
Run pre-commit run black --all-files
Check succeeds
Change black revision in .pre-commit-config.yaml to ‘stable’ or ‘20.8b1’ or ‘master’ (currently it is ‘19.10b0’)
Run pre-commit install
Run pre-commit run black --all-files
You will see a lot of files updated due to changed line length

We keep the line length in pyproject.toml and we even force the pyproject.toml file via extra arg:

  - repo: https://github.com/psf/black
    rev: 19.10b0
    hooks:
      - id: black
        files: api_connexion/.*\.py|.*providers.*\.py
        exclude: .*kubernetes_pod\.py|.*google/common/hooks/base_google\.py$
        args: [--config=./pyproject.toml]

Seems that the behaviour changed very recently - it was working before and people who installed pre-commit recently started to complain about it:

Expected behavior

The line-lenght in pyproject.toml should be respected in black’s pre-commit.

Environment (please complete the following information):

Version: master, 20.8b1, stable, 20.8b0.
MacOS and Python version: Python 3.6.10

Does this bug also happen on master?

Yes. It behaves the same with master set as revision.

Additional context Add any other context about the problem here.

Our pyproject.toml file:

[tool.black]
line-length = 110
target-version = ['py36', 'py37', 'py38']
skip-string-normalization = true

Also tried it with:

    hooks:
      - id: black
        files: api_connexion/.*\.py|.*providers.*\.py
        exclude: .*kubernetes_pod\.py|.*google/common/hooks/base_google\.py$
        args:
          - "--config"
          - "./pyproject.toml"

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 6
Comments: 16 (5 by maintainers)

Most upvoted comments

Is there a flag to control those trailing commas?

😆 kind of the point of black is there’s no options

asottile on Sep 8, 2020

I run into the same issue just passing --line-length=120 in pre-commit config.

mdkess on Sep 2, 2020

😄 thought so that might be the answer - ‘uncompromising’

Thanks, we love ‘black’ and we will soon enable it across entire Apache Airflow (https://github.com/apache/airflow/commits/) code base

kaxil on Sep 8, 2020

and we have auto-complete for all pre-commit checks and … wait for it … … wait for it … we are using pre-commit check to see if all the pre-commits are properly documented

that’s funny, I’ve done the same thing here: https://github.com/pre-commit/pygrep-hooks/blob/eae6397e4c259ed3d057511f6dd5330b92867e62/.pre-commit-config.yaml#L38-L46

glad you like the tool ❤️

asottile on Sep 9, 2020

Agree with Jarek, @asottile Thanks for pre-commit 🙏

kaxil on Sep 9, 2020

And BTW. once again - thanks for pre-commit. It’s a game-changer in automation of software development.

potiuk on Sep 9, 2020

And really - good intentions here 😃. We are both with @kaxil long-time python develiopers and commiters and PMC in Apache Airflow project, and we have a looooooot of automation for our code (we have more than 50 pre-commit checks in Apache Airflow https://github.com/apache/airflow/blob/master/STATIC_CODE_CHECKS.rst#pre-commit-hooks but this one was confusing as hell)

potiuk on Sep 9, 2020

Agree. We do love black 😃. I just have not realised it is a “beta” product 😉. But it took some 12 years for Gmail to get out Beta, so I think we can wait.

@asottile Honestly - as @kaxil said - we love black. My point about the “informing user” is that we both with @kaxil got confused where it came from and until we got the answer from you, we were 100% sure that it’s because of the line length. We even tried hard to enable the right line length and failed. So my point is - in this case when this change is so significant, maybe on top of mentioning it as one of the changes in the changelog (without clear information that it has that much of an impact). there could be a way to kind of warn the user what’s going on ? Just explain the reason why suddenly something changed.

I guess it could be possible to detect that the change applied to 100 files is mostly because of the change in new version and some message at the end "The changes above were introduced by the new rule [“link to description here”] ".

Just a thought. That could save you from having to get/answer the issue and possibly in the next few weeks you will have to do it few more times for others - so investing in this kind of “information” for the user might pay-off rather quickly.

potiuk on Sep 9, 2020