]> git.madduck.net Git - etc/vim.git/blob - docs/contributing/the_basics.md

madduck's git repository

Every one of the projects in this repository is available at the canonical URL git://git.madduck.net/madduck/pub/<projectpath> — see each project's metadata for the exact URL.

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.

SSH access, as well as push access can be individually arranged.

If you use my repositories frequently, consider adding the following snippet to ~/.gitconfig and using the third clone URL listed for each project:

[url "git://git.madduck.net/madduck/"]
  insteadOf = madduck:

Set Docker to use 3.11 for now (#3927)
[etc/vim.git] / docs / contributing / the_basics.md
1 # The basics
2
3 An overview on contributing to the _Black_ project.
4
5 ## Technicalities
6
7 Development on the latest version of Python is preferred. You can use any operating
8 system.
9
10 Install development dependencies inside a virtual environment of your choice, for
11 example:
12
13 ```console
14 $ python3 -m venv .venv
15 $ source .venv/bin/activate # activation for linux and mac
16 $ .venv\Scripts\activate # activation for windows
17
18 (.venv)$ pip install -r test_requirements.txt
19 (.venv)$ pip install -e .[d]
20 (.venv)$ pre-commit install
21 ```
22
23 Before submitting pull requests, run lints and tests with the following commands from
24 the root of the black repo:
25
26 ```console
27 # Linting
28 (.venv)$ pre-commit run -a
29
30 # Unit tests
31 (.venv)$ tox -e py
32
33 # Optional Fuzz testing
34 (.venv)$ tox -e fuzz
35
36 # Format Black itself
37 (.venv)$ tox -e run_self
38 ```
39
40 ### Development
41
42 Further examples of invoking the tests
43
44 ```console
45 # Run all of the above mentioned, in parallel
46 (.venv)$ tox --parallel=auto
47
48 # Run tests on a specific python version
49 (.venv)$ tox -e py39
50
51 # pass arguments to pytest
52 (.venv)$ tox -e py -- --no-cov
53
54 # print full tree diff, see documentation below
55 (.venv)$ tox -e py -- --print-full-tree
56
57 # disable diff printing, see documentation below
58 (.venv)$ tox -e py -- --print-tree-diff=False
59 ```
60
61 `Black` has two pytest command-line options affecting test files in `tests/data/` that
62 are split into an input part, and an output part, separated by a line with`# output`.
63 These can be passed to `pytest` through `tox`, or directly into pytest if not using
64 `tox`.
65
66 #### `--print-full-tree`
67
68 Upon a failing test, print the full concrete syntax tree (CST) as it is after processing
69 the input ("actual"), and the tree that's yielded after parsing the output ("expected").
70 Note that a test can fail with different output with the same CST. This used to be the
71 default, but now defaults to `False`.
72
73 #### `--print-tree-diff`
74
75 Upon a failing test, print the diff of the trees as described above. This is the
76 default. To turn it off pass `--print-tree-diff=False`.
77
78 ### News / Changelog Requirement
79
80 `Black` has CI that will check for an entry corresponding to your PR in `CHANGES.md`. If
81 you feel this PR does not require a changelog entry please state that in a comment and a
82 maintainer can add a `skip news` label to make the CI pass. Otherwise, please ensure you
83 have a line in the following format:
84
85 ```md
86 - `Black` is now more awesome (#X)
87 ```
88
89 Note that X should be your PR number, not issue number! To workout X, please use
90 [Next PR Number](https://ichard26.github.io/next-pr-number/?owner=psf&name=black). This
91 is not perfect but saves a lot of release overhead as now the releaser does not need to
92 go back and workout what to add to the `CHANGES.md` for each release.
93
94 ### Style Changes
95
96 If a change would affect the advertised code style, please modify the documentation (The
97 _Black_ code style) to reflect that change. Patches that fix unintended bugs in
98 formatting don't need to be mentioned separately though. If the change is implemented
99 with the `--preview` flag, please include the change in the future style document
100 instead and write the changelog entry under a dedicated "Preview changes" heading.
101
102 ### Docs Testing
103
104 If you make changes to docs, you can test they still build locally too.
105
106 ```console
107 (.venv)$ pip install -r docs/requirements.txt
108 (.venv)$ pip install -e .[d]
109 (.venv)$ sphinx-build -a -b html -W docs/ docs/_build/
110 ```
111
112 ## Hygiene
113
114 If you're fixing a bug, add a test. Run it first to confirm it fails, then fix the bug,
115 run it again to confirm it's really fixed.
116
117 If adding a new feature, add a test. In fact, always add a test. But wait, before adding
118 any large feature, first open an issue for us to discuss the idea first.
119
120 ## Finally
121
122 Thanks again for your interest in improving the project! You're taking action when most
123 people decide to sit and watch.