CONTRIBUTING.md

   1 # Contributing to _Black_
   2
   3 Welcome! Happy to see you willing to make the project better. Have you read the entire
   4 [user documentation](https://black.readthedocs.io/en/latest/) yet?
   5
   6 ## Bird's eye view
   7
   8 In terms of inspiration, _Black_ is about as configurable as _gofmt_. This is
   9 deliberate.
  10
  11 Bug reports and fixes are always welcome! Please follow the
  12 [issue template on GitHub](https://github.com/psf/black/issues/new) for best results.
  13
  14 Before you suggest a new feature or configuration knob, ask yourself why you want it. If
  15 it enables better integration with some workflow, fixes an inconsistency, speeds things
  16 up, and so on - go for it! On the other hand, if your answer is "because I don't like a
  17 particular formatting" then you're not ready to embrace _Black_ yet. Such changes are
  18 unlikely to get accepted. You can still try but prepare to be disappointed.
  19
  20 ## Technicalities
  21
  22 Development on the latest version of Python is preferred. As of this writing it's 3.9.
  23 You can use any operating system. I am using macOS myself and CentOS at work.
  24
  25 Install all development dependencies using:
  26
  27 ```console
  28 $ pipenv install --dev
  29 $ pipenv shell
  30 $ pre-commit install
  31 ```
  32
  33 If you haven't used `pipenv` before but are comfortable with virtualenvs, just run
  34 `pip install pipenv` in the virtualenv you're already using and invoke the command above
  35 from the cloned _Black_ repo. It will do the correct thing.
  36
  37 Non pipenv install works too:
  38
  39 ```console
  40 $ pip install -r test_requirements
  41 $ pip install -e .[d]
  42 ```
  43
  44 Before submitting pull requests, run lints and tests with the following commands from
  45 the root of the black repo:
  46
  47 ```console
  48 # Linting
  49 $ pre-commit run -a
  50
  51 # Unit tests
  52 $ tox -e py
  53
  54 # Optional Fuzz testing
  55 $ tox -e fuzz
  56
  57 # Optional CI run to test your changes on many popular python projects
  58 $ black-primer [-k -w /tmp/black_test_repos]
  59 ```
  60
  61 ### News / Changelog Requirement
  62
  63 `Black` has CI that will check for an entry corresponding to your PR in `CHANGES.md`. If
  64 you feel this PR not require a changelog entry please state that in a comment and a
  65 maintainer can add a `skip news` label to make the CI pass. Otherwise, please ensure you
  66 have a line in the following format:
  67
  68 ```md
  69 - `Black` is now more awesome (#X)
  70 ```
  71
  72 To workout X, please use
  73 [Next PR Number](https://ichard26.github.io/next-pr-number/?owner=psf&name=black). This
  74 is not perfect but saves a lot of release overhead as now the releaser does not need to
  75 go back and workout what to add to the `CHANGES.md` for each release.
  76
  77 ### Style Changes
  78
  79 If a change would affect the advertised code style, please modify the documentation (The
  80 _Black_ code style) to reflect that change. Patches that fix unintended bugs in
  81 formatting don't need to be mentioned separately though.
  82
  83 ### Docs Testing
  84
  85 If you make changes to docs, you can test they still build locally too.
  86
  87 ```console
  88 $ pip install -r docs/requirements.txt
  89 $ pip install [-e] .[d]
  90 $ sphinx-build -a -b html -W docs/ docs/_build/
  91 ```
  92
  93 ## black-primer
  94
  95 `black-primer` is used by CI to pull down well-known _Black_ formatted projects and see
  96 if we get source code changes. It will error on formatting changes or errors. Please run
  97 before pushing your PR to see if you get the actions you would expect from _Black_ with
  98 your PR. You may need to change
  99 [primer.json](https://github.com/psf/black/blob/master/src/black_primer/primer.json)
 100 configuration for it to pass.
 101
 102 For more `black-primer` information visit the
 103 [documentation](https://github.com/psf/black/blob/master/docs/black_primer.md).
 104
 105 ## Hygiene
 106
 107 If you're fixing a bug, add a test. Run it first to confirm it fails, then fix the bug,
 108 run it again to confirm it's really fixed.
 109
 110 If adding a new feature, add a test. In fact, always add a test. But wait, before adding
 111 any large feature, first open an issue for us to discuss the idea first.
 112
 113 ## Finally
 114
 115 Thanks again for your interest in improving the project! You're taking action when most
 116 people decide to sit and watch.