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. As of this writing it's 3.9.
   8 You can use any operating 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
  16 (.venv)$ pip install -r test_requirements.txt
  17 (.venv)$ pip install -e .[d]
  18 (.venv)$ pre-commit install
  19 ```
  20
  21 Before submitting pull requests, run lints and tests with the following commands from
  22 the root of the black repo:
  23
  24 ```console
  25 # Linting
  26 (.venv)$ pre-commit run -a
  27
  28 # Unit tests
  29 (.venv)$ tox -e py
  30
  31 # Optional Fuzz testing
  32 (.venv)$ tox -e fuzz
  33
  34 # Optional CI run to test your changes on many popular python projects
  35 (.venv)$ black-primer [-k -w /tmp/black_test_repos]
  36 ```
  37
  38 ### News / Changelog Requirement
  39
  40 `Black` has CI that will check for an entry corresponding to your PR in `CHANGES.md`. If
  41 you feel this PR does not require a changelog entry please state that in a comment and a
  42 maintainer can add a `skip news` label to make the CI pass. Otherwise, please ensure you
  43 have a line in the following format:
  44
  45 ```md
  46 - `Black` is now more awesome (#X)
  47 ```
  48
  49 Note that X should be your PR number, not issue number! To workout X, please use
  50 [Next PR Number](https://ichard26.github.io/next-pr-number/?owner=psf&name=black). This
  51 is not perfect but saves a lot of release overhead as now the releaser does not need to
  52 go back and workout what to add to the `CHANGES.md` for each release.
  53
  54 ### Style Changes
  55
  56 If a change would affect the advertised code style, please modify the documentation (The
  57 _Black_ code style) to reflect that change. Patches that fix unintended bugs in
  58 formatting don't need to be mentioned separately though. If the change is implemented
  59 with the `--preview` flag, please include the change in the future style document
  60 instead and write the changelog entry under a dedicated "Preview changes" heading.
  61
  62 ### Docs Testing
  63
  64 If you make changes to docs, you can test they still build locally too.
  65
  66 ```console
  67 (.venv)$ pip install -r docs/requirements.txt
  68 (.venv)$ pip install [-e] .[d]
  69 (.venv)$ sphinx-build -a -b html -W docs/ docs/_build/
  70 ```
  71
  72 ## black-primer
  73
  74 `black-primer` is used by CI to pull down well-known _Black_ formatted projects and see
  75 if we get source code changes. It will error on formatting changes or errors. Please run
  76 before pushing your PR to see if you get the actions you would expect from _Black_ with
  77 your PR. You may need to change
  78 [primer.json](https://github.com/psf/black/blob/main/src/black_primer/primer.json)
  79 configuration for it to pass.
  80
  81 For more `black-primer` information visit the
  82 [documentation](./gauging_changes.md#black-primer).
  83
  84 ## Hygiene
  85
  86 If you're fixing a bug, add a test. Run it first to confirm it fails, then fix the bug,
  87 run it again to confirm it's really fixed.
  88
  89 If adding a new feature, add a test. In fact, always add a test. But wait, before adding
  90 any large feature, first open an issue for us to discuss the idea first.
  91
  92 ## Finally
  93
  94 Thanks again for your interest in improving the project! You're taking action when most
  95 people decide to sit and watch.