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