Feature Request - add required black version in pyproject.toml

[jvanasco]

Many projects that I contribute to have adopted black. (Congrats and Thank You!)

An issue which has come up in multiple projects is automatic tests failing because of differences in the installed black versions between environments.

For example: a project may indicate a particular version of black in a pre-commit configuration in .pre-commit-config.yaml (https://black.readthedocs.io/en/stable/version_control_integration.html) which will re-format the code to that version... but that will not-necessarily be the same version which is invoked by the local developer or the build/deploy service - as black will consult the pyproject.toml file instead (https://black.readthedocs.io/en/stable/pyproject_toml.html).

This can create issues on automated tests, because the server environment may be configured to install 19.3b0 while the hook or developer's environment is formatting to 19.10b0. This can suggest a developer didn't run black or made an error, when the build/deploy system is what requires adjustment.

A potential solution is to extend the pyproject.toml configuration to have an argument which states the required version:

[tool.black]
line-length = 88
rev = 19.10b0

If specified, black would then raise a fatal exception if invoked with a version that does not match. Perhaps a commandline flag is needed to avoid this for certain causes. Some projects specify a specific version of black for a particular test environment in tox.ini, but nothing is global.

An alternative might also include migrating the version declaration from the .pre-commit-config.yaml into the pyproject.toml file, where it seems to be more applicable. However, I assume the revision was declared in this file for important reasons I do not understand yet.

To summarize:

• pre-config integration is great, but if a contributor doesn't have pre-commit installed, they'll invoke black directly
• if a contributor invokes black directly, they may format the code with a different version than the project uses
• automated systems can pick up a new version of black; by may not pin the version in the tox config for the test. or they use travis.

having a centralized version pin, instead of requiring a version pin for each context, would eliminate many problems.

Thank you.

see also: #420

[Hyperx837]

I guess poetry can solve this. try convince your team to use poetry. I don't know any other solutions than this

[JelleZijlstra]

I agree that this is a useful feature and I'd welcome a PR implementing it. Sorry for the lack of response earlier.