|
3 | 3 | We'd love to accept your patches and contributions to this project. There are
|
4 | 4 | just a few small guidelines you need to follow.
|
5 | 5 |
|
| 6 | +## Getting started |
| 7 | + |
| 8 | +Before we can work on the code, we need to get a copy of it and setup some |
| 9 | +local environment and tools. |
| 10 | + |
| 11 | +First, fork the code to your user and clone your fork. This gives you a private |
| 12 | +playground where you can do any edits you'd like. For this guide, we'll use |
| 13 | +the [GitHub `gh` tool](https://github.com/cli/cli) |
| 14 | +([Linux install](https://github.com/cli/cli/blob/trunk/docs/install_linux.md)). |
| 15 | +(More advanced users may prefer the GitHub UI and raw `git` commands). |
| 16 | + |
| 17 | +```shell |
| 18 | +gh repo fork bazelbuild/rules_python --clone --remote |
| 19 | +``` |
| 20 | + |
| 21 | +Next, make sure you have a new enough version of Python installed that supports the |
| 22 | +various code formatters and other devtools. For a quick start, |
| 23 | +[install pyenv](https://github.com/pyenv/pyenv-installer) and |
| 24 | +at least Python 3.9.15: |
| 25 | + |
| 26 | +```shell |
| 27 | +curl https://pyenv.run | bash |
| 28 | +pyenv install 3.9.15 |
| 29 | +pyenv shell 3.9.15 |
| 30 | +``` |
| 31 | + |
| 32 | +## Development workflow |
| 33 | + |
| 34 | +It's suggested that you create what is called a "feature/topic branch" in your |
| 35 | +fork when you begin working on code you want to eventually send or code review. |
| 36 | + |
| 37 | +``` |
| 38 | +git checkout main # Start our branch from the latest code |
| 39 | +git checkout -b my-feature # Create and switch to our feature branch |
| 40 | +git push origin my-feature # Cause the branch to be created in your fork. |
| 41 | +``` |
| 42 | + |
| 43 | +From here, you then edit code and commit to your local branch. If you want to |
| 44 | +save your work to github, you use `git push` to do so: |
| 45 | + |
| 46 | +``` |
| 47 | +git push origin my-feature |
| 48 | +``` |
| 49 | + |
| 50 | +Once the code is in your github repo, you can then turn it into a Pull Request |
| 51 | +to the actual rules_python project and begin the code review process. |
| 52 | + |
| 53 | + |
| 54 | +## Running tests |
| 55 | + |
| 56 | +Running tests is particularly easy thanks to Bazel, simply run: |
| 57 | + |
| 58 | +``` |
| 59 | +bazel test //... |
| 60 | +``` |
| 61 | + |
| 62 | +And it will run all the tests it can find. The first time you do this, it will |
| 63 | +probably take long time because various dependencies will need to be downloaded |
| 64 | +and setup. Subsequent runs will be faster, but there are many tests, and some of |
| 65 | +them are slow. If you're working on a particular area of code, you can run just |
| 66 | +the tests in those directories instead, which can speed up your edit-run cycle. |
| 67 | + |
| 68 | +Note that there are tests to verify generated documentation is correct -- if |
| 69 | +you're modifying the signature of a public function, these tests will likely |
| 70 | +fail and you'll need to [regenerate the api docs](#documentation). |
| 71 | + |
6 | 72 | ## Formatting
|
7 | 73 |
|
8 |
| -Starlark files should be formatted by buildifier. |
9 |
| -Otherwise the Buildkite CI will yell at you about formatting/linting violations. |
| 74 | +Starlark files should be formatted by |
| 75 | +[buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md). |
| 76 | +Otherwise the Buildkite CI will fail with formatting/linting violations. |
10 | 77 | We suggest using a pre-commit hook to automate this.
|
11 | 78 | First [install pre-commit](https://pre-commit.com/#installation),
|
12 | 79 | then run
|
13 | 80 |
|
14 | 81 | ```shell
|
15 | 82 | pre-commit install
|
16 | 83 | ```
|
| 84 | + |
17 | 85 | ### Running buildifer manually
|
18 | 86 |
|
19 |
| -If you choose to run buildifier manually, run the following command: |
| 87 | +You can also run buildifier manually. To do this, |
| 88 | +[install buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md), |
| 89 | +and run the following command: |
20 | 90 |
|
21 | 91 | ```shell
|
22 | 92 | $ buildifier --lint=fix --warnings=native-py -warnings=all WORKSPACE
|
@@ -84,3 +154,23 @@ Issues should be triaged as follows:
|
84 | 154 | - Anything else, such as feature requests not related to existing core rules
|
85 | 155 | functionality, should also be filed in this repository but without the
|
86 | 156 | `core-rules` label.
|
| 157 | + |
| 158 | +## FAQ |
| 159 | + |
| 160 | +### Installation errors when during `git commit` |
| 161 | + |
| 162 | +If you did `pre-commit install`, various tools are run when you do `git commit`. |
| 163 | +This might show as an error such as: |
| 164 | + |
| 165 | +``` |
| 166 | +[INFO] Installing environment for https://github.com/psf/black. |
| 167 | +[INFO] Once installed this environment will be reused. |
| 168 | +[INFO] This may take a few minutes... |
| 169 | +An unexpected error has occurred: CalledProcessError: command: ... |
| 170 | +``` |
| 171 | + |
| 172 | +To fix, you'll need to figure out what command is failing and why. Because these |
| 173 | +are tools that run locally, its likely you'll need to fix something with your |
| 174 | +environment or the installation of the tools. For Python tools (e.g. black or |
| 175 | +isort), you can try using a different Python version in your shell by using |
| 176 | +tools such as [pyenv](https://github.com/pyenv/pyenv). |
0 commit comments