Python black setup cfg

configparser-black

Black supports pyproject.toml and global configuration natively.

This module ignores setup.cfg and tox.ini black related configurations if there is a [tool.black] section in your pyproject.toml This module will pass the configuration to black as command line arguments, meaning that it will override any configuration you have in your global black files in

• Windows ~\.black
• Linux/MacOS: $XDG_CONFIG_HOME/black ( ~/.config/black if the XDG_CONFIG_HOME environment variable is not set)

If there is no pyproject.toml it will lookup for configuration in

with the higher number superseeding lower numbers (i.e tox.ini overrides any black configuration found in setup.cfg )

setup.cfg

Example configuration in setup.cfg

black --quiet --line-length  --target-version py37 --include  --check ./

tox.ini

Same configuration in tox.ini

Similarly black will run with

black --line-length  --target-version py36 --target-version py37 --include  --extend-exclude  ./

Notes

Quotes

Quotes will be stripped from values from start and end. Also there is no need to escape quotes in the middle of a string.

black --include black --include somerandomfile

black --include If you want to include quotes you can wrap in single if you want double or double if you want single i.e

black --include  --extend-exclude 
Источник

Using Black with other tools#
All of Black’s changes are harmless (or at least, they should be), but a few do conflict against other tools. It is not uncommon to be using other tools alongside Black like linters and type checkers. Some of them need a bit of tweaking to resolve the conflicts. Listed below are Black compatible configurations in various formats for the common tools out there. Please note that Black only supports the TOML file format for its configuration (e.g. pyproject.toml ). The provided examples are to only configure their corresponding tools, using their supported file formats. Compatible configuration files can be found here.
isort#
isort helps to sort and format imports in your Python code. Black also formats imports, but in a different way from isort’s defaults which leads to conflicting changes.
Profile#
Since version 5.0.0, isort supports profiles to allow easy interoperability with common code styles. You can set the black profile in any of the config files supported by isort. Below, an example for pyproject.toml :
Custom Configuration#
If you’re using an isort version that is older than 5.0.0 or you have some custom configuration for Black, you can tweak your isort configuration to make it compatible with Black. Below, an example for .isort.cfg :
multi_line_output = 3 include_trailing_comma = True force_grid_wrap = 0 use_parentheses = True ensure_newline_before_comments = True line_length = 88 
 
Why those options above?#
 
Black wraps imports that surpass line-length by moving identifiers onto separate lines and by adding a trailing comma after each. A more detailed explanation of this behaviour can be found here . isort’s default mode of wrapping imports that extend past the line_length limit is “Grid”.
 
from third_party import (lib1, lib2, lib3, lib4, lib5, . ) 
 
This style is incompatible with Black, but isort can be configured to use a different wrapping mode called “Vertical Hanging Indent” which looks like this:
 
from third_party import ( lib1, lib2, lib3, lib4, ) 
 
This style is Black compatible and can be achieved by multi-line-output = 3 . Also, as mentioned above, when wrapping long imports Black puts a trailing comma and uses parentheses. isort should follow the same behaviour and passing the options include_trailing_comma = True and use_parentheses = True configures that. The option force_grid_wrap = 0 is just to tell isort to only wrap imports that surpass the line_length limit. Finally, isort should be told to wrap imports when they surpass Black’s default limit of 88 characters via line_length = 88 as well as ensure_newline_before_comments = True to ensure spacing import sections with comments works the same as with Black. Please note ensure_newline_before_comments = True only works since isort >= 5 but does not break older versions so you can keep it if you are running previous versions.
 
Formats#
 
Flake8#
 
Flake8 is a code linter. It warns you of syntax errors, possible bugs, stylistic errors, etc. For the most part, Flake8 follows PEP 8 when warning about stylistic errors. There are a few deviations that cause incompatibilities with Black.
 
Configuration#
 
max-line-length = 88 extend-ignore = E203 
 
Why those options above?#
 
In some cases, as determined by PEP 8, Black will enforce an equal amount of whitespace around slice operators. Due to this, Flake8 will raise E203 whitespace before ':' warnings. Since this warning is not PEP 8 compliant, Flake8 should be configured to ignore it via extend-ignore = E203 . When breaking a line, Black will break it before a binary operator. This is compliant with PEP 8 as of April 2016. There’s a disabled-by-default warning in Flake8 which goes against this PEP 8 recommendation called W503 line break before binary operator . It should not be enabled in your configuration. Also, as like with isort, flake8 should be configured to allow lines up to the length limit of 88 , Black’s default. This explains max-line-length = 88 .
 
Formats#
 
[flake8] max-line-length = 88 extend-ignore = E203 
 
[flake8] max-line-length = 88 extend-ignore = E203 
 
[flake8] max-line-length = 88 extend-ignore = E203 
 
Pylint#
 
Pylint is also a code linter like Flake8. It has the same checks as flake8 and more. In particular, it has more formatting checks regarding style conventions like variable naming. With so many checks, Pylint is bound to have some mixed feelings about Black’s formatting style.
 
Configuration#
 
Why those options above?#
 
Pylint should be configured to only complain about lines that surpass 88 characters via max-line-length = 88 . If using pylint<2.6.0 , also disable C0326 and C0330 as these are incompatible with Black formatting and have since been removed.
 
Formats#
 
[tool.pylint.format] max-line-length = "88" 
 
pycodestyle#
 
Configuration#
 
max-line-length = 88 ignore = E203 
 
Why those options above?#
 
pycodestyle should be configured to only complain about lines that surpass 88 characters via max_line_length = 88 . See Why are Flake8’s E203 and W503 violated?
 
Formats#
 
[pycodestyle] ignore = E203 max_line_length = 88 
 
Источник
 
Saved searches
 
Use saved searches to filter your results more quickly
 
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
 
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
 
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
 
Already on GitHub? Sign in to your account
 
Support config in setup.cfg #688
 
 Support config in setup.cfg #688
 
Comments
 
Today, the config of black is exclusively in pyproject.toml.
 
However some project relies on setuptools.setup() rather than Flit.
 
Would it be possible to also store the config in setup.cfg? 
Especially since the syntax would be the same?
 
[tool.black] line-length = 99 include = \.pyi?$ exclude = \.git | \.hg | \.mypy_cache | \.tox | \.venv | _build | buck-out | build | dist 
 
Note that other projects like zest.releaser, flake8, twine, wheel already support that.
 
The text was updated successfully, but these errors were encountered:
 
@richardARPANET maybe we should work on flake8 and other projects to support pyproject.toml?
 
@JulianVolodia just because the black maintainer is stubborn? Pass
 
 
@JulianVolodia just because the black maintainer is stubborn? Pass
 
 
Main reason to support setup.cfg is because it would allow to have flake/pyling/isort/black/pytest/coverage settings in one neat file. Thanks to this root directory is clean and simple running of flake8; isort; pytest --cov .
 
I understand though - migrate to toml. But here flake also doesn't support it - https://gitlab.com/pycqa/flake8/-/issues/428.
 
@mateusz-stint but they wont even bc of that. I am thinking about automatic tracking of black mainstream for brunette
 
@ambv I don't want to create a special issue for that, so I will just put my question here - the current adoption of pyproject.toml is much better than a few years ago, from my experience - almost all crucial Python dev tools already support it. The biggest blocker for a full migration to pyproject.toml -only setup is flake8 . I just wonder have you ever discussed with guys to convince them to add support for pyproject.toml ? I know they don't really bother about community requests because of their own opinions about TOML, but as the DIR maybe you would be able to change their attitude? Even the tox -like legacy support would be a big step forward here.
 
Imho the integrity of the dev ecosystem is pretty important for each language, and in case of Python it was quite problematic for years, but now we are in a state where we are really close to achieve that goal in terms of project configuration, next and next PEPs highlight the importance of pyproject.toml . It would be a real pity if these efforts would be anyhow impacted just because of one or two guys. Especially when flake8 is a part of PyCQA, and it would be beneficial for all if PSF and PyCQA were in the same boat here.
 
Usually we can figure such issues just as a Python community, but unfortunately - that's not the case here 😕
 
Источник
 
Читайте также:  Test if java is 64 bit