1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
|
# How to contribute
We'd love to accept your patches and contributions to this project. There are
just a few small guidelines you need to follow.
## Getting started
Before we can work on the code, we need to get a copy of it and setup some
local environment and tools.
First, fork the code to your user and clone your fork. This gives you a private
playground where you can do any edits you'd like. For this guide, we'll use
the [GitHub `gh` tool](https://github.com/cli/cli)
([Linux install](https://github.com/cli/cli/blob/trunk/docs/install_linux.md)).
(More advanced users may prefer the GitHub UI and raw `git` commands).
```shell
gh repo fork bazelbuild/rules_python --clone --remote
```
Next, make sure you have a new enough version of Python installed that supports the
various code formatters and other devtools. For a quick start,
[install pyenv](https://github.com/pyenv/pyenv-installer) and
at least Python 3.9.15:
```shell
curl https://pyenv.run | bash
pyenv install 3.9.15
pyenv shell 3.9.15
```
## Development workflow
It's suggested that you create what is called a "feature/topic branch" in your
fork when you begin working on code you want to eventually send or code review.
```
git checkout main # Start our branch from the latest code
git checkout -b my-feature # Create and switch to our feature branch
git push origin my-feature # Cause the branch to be created in your fork.
```
From here, you then edit code and commit to your local branch. If you want to
save your work to github, you use `git push` to do so:
```
git push origin my-feature
```
Once the code is in your github repo, you can then turn it into a Pull Request
to the actual rules_python project and begin the code review process.
## Running tests
Running tests is particularly easy thanks to Bazel, simply run:
```
bazel test //...
```
And it will run all the tests it can find. The first time you do this, it will
probably take long time because various dependencies will need to be downloaded
and setup. Subsequent runs will be faster, but there are many tests, and some of
them are slow. If you're working on a particular area of code, you can run just
the tests in those directories instead, which can speed up your edit-run cycle.
Note that there are tests to verify generated documentation is correct -- if
you're modifying the signature of a public function, these tests will likely
fail and you'll need to [regenerate the api docs](#documentation).
## Formatting
Starlark files should be formatted by
[buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md).
Otherwise the Buildkite CI will fail with formatting/linting violations.
We suggest using a pre-commit hook to automate this.
First [install pre-commit](https://pre-commit.com/#installation),
then run
```shell
pre-commit install
```
### Running buildifer manually
You can also run buildifier manually. To do this,
[install buildifier](https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md),
and run the following command:
```shell
$ buildifier --lint=fix --warnings=native-py -warnings=all WORKSPACE
```
Replace the argument "WORKSPACE" with the file that you are linting.
## Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License
Agreement. You (or your employer) retain the copyright to your contribution,
this simply gives us permission to use and redistribute your contributions as
part of the project. Head over to <https://cla.developers.google.com/> to see
your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one
(even if it was for a different project), you probably don't need to do it
again.
## Code reviews
All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult [GitHub Help] for more
information on using pull requests.
[GitHub Help]: https://help.github.com/articles/about-pull-requests/
### Commit messages
Commit messages (upon merging) and PR messages should follow the [Conventional
Commits](https://www.conventionalcommits.org/) style:
```
type(scope)!: <summary>
<body>
BREAKING CHANGE: <summary>
```
Where `(scope)` is optional, and `!` is only required if there is a breaking change.
If a breaking change is introduced, then `BREAKING CHANGE:` is required.
Common `type`s:
* `build:` means it affects the building or development workflow.
* `docs:` means only documentation is being added, updated, or fixed.
* `feat:` means a user-visible feature is being added.
* `fix:` means a user-visible behavior is being fixed.
* `refactor:` means some sort of code cleanup that doesn't change user-visible behavior.
* `revert:` means a prior change is being reverted in some way.
* `test:` means only tests are being added.
For the full details of types, see
[Conventional Commits](https://www.conventionalcommits.org/).
## Generated files
Some checked-in files are generated and need to be updated when a new PR is
merged.
### Documentation
To regenerate the content under the `docs/` directory, run this command:
```shell
bazel run //docs:update
```
This needs to be done whenever the docstrings in the corresponding .bzl files
are changed; a test failure will remind you to run this command when needed.
## Core rules
The bulk of this repo is owned and maintained by the Bazel Python community.
However, since the core Python rules (`py_binary` and friends) are still
bundled with Bazel itself, the Bazel team retains ownership of their stubs in
this repository. This will be the case at least until the Python rules are
fully migrated to Starlark code.
Practically, this means that a Bazel team member should approve any PR
concerning the core Python logic. This includes everything under the `python/`
directory except for `pip.bzl` and `requirements.txt`.
Issues should be triaged as follows:
- Anything concerning the way Bazel implements the core Python rules should be
filed under [bazelbuild/bazel](https://github.com/bazelbuild/bazel), using
the label `team-Rules-python`.
- If the issue specifically concerns the rules_python stubs, it should be filed
here in this repository and use the label `core-rules`.
- Anything else, such as feature requests not related to existing core rules
functionality, should also be filed in this repository but without the
`core-rules` label.
## FAQ
### Installation errors when during `git commit`
If you did `pre-commit install`, various tools are run when you do `git commit`.
This might show as an error such as:
```
[INFO] Installing environment for https://github.com/psf/black.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: CalledProcessError: command: ...
```
To fix, you'll need to figure out what command is failing and why. Because these
are tools that run locally, its likely you'll need to fix something with your
environment or the installation of the tools. For Python tools (e.g. black or
isort), you can try using a different Python version in your shell by using
tools such as [pyenv](https://github.com/pyenv/pyenv).
|
