All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
3 An overview on contributing to the _Black_ project.
7 Development on the latest version of Python is preferred. You can use any operating
10 Install development dependencies inside a virtual environment of your choice, for
14 $ python3 -m venv .venv
15 $ source .venv/bin/activate # activation for linux and mac
16 $ .venv\Scripts\activate # activation for windows
18 (.venv)$ pip install -r test_requirements.txt
19 (.venv)$ pip install -e .[d]
20 (.venv)$ pre-commit install
23 Before submitting pull requests, run lints and tests with the following commands from
24 the root of the black repo:
28 (.venv)$ pre-commit run -a
33 # Optional Fuzz testing
37 (.venv)$ tox -e run_self
42 Further examples of invoking the tests
45 # Run all of the above mentioned, in parallel
46 (.venv)$ tox --parallel=auto
48 # Run tests on a specific python version
51 # pass arguments to pytest
52 (.venv)$ tox -e py -- --no-cov
54 # print full tree diff, see documentation below
55 (.venv)$ tox -e py -- --print-full-tree
57 # disable diff printing, see documentation below
58 (.venv)$ tox -e py -- --print-tree-diff=False
63 All aspects of the _Black_ style should be tested. Normally, tests should be created as
64 files in the `tests/data/cases` directory. These files consist of up to three parts:
66 - A line that starts with `# flags: ` followed by a set of command-line options. For
67 example, if the line is `# flags: --preview --skip-magic-trailing-comma`, the test
68 case will be run with preview mode on and the magic trailing comma off. The options
69 accepted are mostly a subset of those of _Black_ itself, except for the
70 `--minimum-version=` flag, which should be used when testing a grammar feature that
71 works only in newer versions of Python. This flag ensures that we don't try to
72 validate the AST on older versions and tests that we autodetect the Python version
73 correctly when the feature is used. For the exact flags accepted, see the function
74 `get_flags_parser` in `tests/util.py`. If this line is omitted, the default options
76 - A block of Python code used as input for the formatter.
77 - The line `# output`, followed by the output of _Black_ when run on the previous block.
78 If this is omitted, the test asserts that _Black_ will leave the input code unchanged.
80 _Black_ has two pytest command-line options affecting test files in `tests/data/` that
81 are split into an input part, and an output part, separated by a line with`# output`.
82 These can be passed to `pytest` through `tox`, or directly into pytest if not using
85 #### `--print-full-tree`
87 Upon a failing test, print the full concrete syntax tree (CST) as it is after processing
88 the input ("actual"), and the tree that's yielded after parsing the output ("expected").
89 Note that a test can fail with different output with the same CST. This used to be the
90 default, but now defaults to `False`.
92 #### `--print-tree-diff`
94 Upon a failing test, print the diff of the trees as described above. This is the
95 default. To turn it off pass `--print-tree-diff=False`.
97 ### News / Changelog Requirement
99 `Black` has CI that will check for an entry corresponding to your PR in `CHANGES.md`. If
100 you feel this PR does not require a changelog entry please state that in a comment and a
101 maintainer can add a `skip news` label to make the CI pass. Otherwise, please ensure you
102 have a line in the following format:
105 - `Black` is now more awesome (#X)
108 Note that X should be your PR number, not issue number! To workout X, please use
109 [Next PR Number](https://ichard26.github.io/next-pr-number/?owner=psf&name=black). This
110 is not perfect but saves a lot of release overhead as now the releaser does not need to
111 go back and workout what to add to the `CHANGES.md` for each release.
115 If a change would affect the advertised code style, please modify the documentation (The
116 _Black_ code style) to reflect that change. Patches that fix unintended bugs in
117 formatting don't need to be mentioned separately though. If the change is implemented
118 with the `--preview` flag, please include the change in the future style document
119 instead and write the changelog entry under a dedicated "Preview changes" heading.
123 If you make changes to docs, you can test they still build locally too.
126 (.venv)$ pip install -r docs/requirements.txt
127 (.venv)$ pip install -e .[d]
128 (.venv)$ sphinx-build -a -b html -W docs/ docs/_build/
133 If you're fixing a bug, add a test. Run it first to confirm it fails, then fix the bug,
134 run it again to confirm it's really fixed.
136 If adding a new feature, add a test. In fact, always add a test. But wait, before adding
137 any large feature, first open an issue for us to discuss the idea first.
141 Thanks again for your interest in improving the project! You're taking action when most
142 people decide to sit and watch.