Skip to content

Commit ae2fee1

Browse files
authored
docs(gazelle): Migrate Gazelle docs to ReadTheDocs, part 5/5: target types (#3147)
Part of #3082 5th of ~~5~~ 6 PRs. + Migrate target types docs from `gazelle/README.md` to `gazelle/docs/installation_and_usage.md` + `Libraries` section: + Update wording + list for the generation mode types + `Binaries` section: + Slight rewording + `note` block instead of simple "Note that ..." + Mechanical updates: + Wrap at ~80 chars + Use MyST directives and roles.
1 parent 7682924 commit ae2fee1

File tree

2 files changed

+83
-70
lines changed

2 files changed

+83
-70
lines changed

gazelle/README.md

Lines changed: 0 additions & 70 deletions
Original file line numberDiff line numberDiff line change
@@ -6,76 +6,6 @@ ReadTheDocs. Please see https://rules-python.readthedocs.io/gazelle/docs/index.h
66
:::
77

88

9-
### Libraries
10-
11-
Python source files are those ending in `.py` but not ending in `_test.py`.
12-
13-
First, we look for the nearest ancestor BUILD file starting from the folder
14-
containing the Python source file.
15-
16-
In package generation mode, if there is no `py_library` in this BUILD file, one
17-
is created using the package name as the target's name. This makes it the
18-
default target in the package. Next, all source files are collected into the
19-
`srcs` of the `py_library`.
20-
21-
In project generation mode, all source files in subdirectories (that don't have
22-
BUILD files) are also collected.
23-
24-
In file generation mode, each file is given its own target.
25-
26-
Finally, the `import` statements in the source files are parsed, and
27-
dependencies are added to the `deps` attribute.
28-
29-
### Unit Tests
30-
31-
A `py_test` target is added to the BUILD file when gazelle encounters
32-
a file named `__test__.py`.
33-
Often, Python unit test files are named with the suffix `_test`.
34-
For example, if we had a folder that is a package named "foo" we could have a Python file named `foo_test.py`
35-
and gazelle would create a `py_test` block for the file.
36-
37-
The following is an example of a `py_test` target that gazelle would add when
38-
it encounters a file named `__test__.py`.
39-
40-
```starlark
41-
py_test(
42-
name = "build_file_generation_test",
43-
srcs = ["__test__.py"],
44-
main = "__test__.py",
45-
deps = [":build_file_generation"],
46-
)
47-
```
48-
49-
You can control the naming convention for test targets by adding a gazelle directive named
50-
`# gazelle:python_test_naming_convention`. See the instructions in the section above that
51-
covers directives.
52-
53-
### Binaries
54-
55-
When a `__main__.py` file is encountered, this indicates the entry point
56-
of a Python program. A `py_binary` target will be created, named `[package]_bin`.
57-
58-
When no such entry point exists, Gazelle will look for a line like this in the top level in every module:
59-
60-
```python
61-
if __name == "__main__":
62-
```
63-
64-
Gazelle will create a `py_binary` target for every module with such a line, with
65-
the target name the same as the module name.
66-
67-
If `python_generation_mode` is set to `file`, then instead of one `py_binary`
68-
target per module, Gazelle will create one `py_binary` target for each file with
69-
such a line, and the name of the target will match the name of the script.
70-
71-
Note that it's possible for another script to depend on a `py_binary` target and
72-
import from the `py_binary`'s scripts. This can have possible negative effects on
73-
Bazel analysis time and runfiles size compared to depending on a `py_library`
74-
target. The simplest way to avoid these negative effects is to extract library
75-
code into a separate script without a `main` line. Gazelle will then create a
76-
`py_library` target for that library code, and other scripts can depend on that
77-
`py_library` target.
78-
799
## Developer Notes
8010

8111
Gazelle extensions are written in Go.

gazelle/docs/installation_and_usage.md

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -149,3 +149,86 @@ gazelle(
149149

150150
That's it, now you can finally run `bazel run //:gazelle` anytime
151151
you edit Python code, and it should update your `BUILD` files correctly.
152+
153+
154+
## Target Types and How They're Generated
155+
156+
### Libraries
157+
158+
Python source files are those ending in `.py` that are not matched as a test
159+
file via the `# gazelle:python_test_file_pattern` directive. By default,
160+
python source files are all `*.py` files except for `*_test.py` and
161+
`test_*.py`.
162+
163+
First, we look for the nearest ancestor `BUILD(.bazel)` file starting from
164+
the folder containing the Python source file.
165+
166+
+ In `package` generation mode, if there is no {bzl:obj}`py_library` in this
167+
`BUILD(.bazel)` file, one is created using the package name as the target's
168+
name. This makes it the default target in the package. Next, all source
169+
files are collected into the `srcs` of the {bzl:obj}`py_library`.
170+
+ In `project` generation mode, all source files in subdirectories (that don't
171+
have `BUILD(.bazel)` files) are also collected.
172+
+ In `file` generation mode, each python source file is given its own target.
173+
174+
Finally, the `import` statements in the source files are parsed and
175+
dependencies are added to the `deps` attribute of the target.
176+
177+
178+
### Tests
179+
180+
A {bzl:obj}`py_test` target is added to the `BUILD(.bazel)` file when gazelle
181+
encounters a file named `__test__.py` or when files matching the
182+
`# gazelle:python_test_file_pattern` directive are found.
183+
184+
For example, if we had a folder that is a package named "foo" we could have a
185+
Python file named `foo_test.py` and gazelle would create a {bzl:obj}`py_test`
186+
block for the file.
187+
188+
The following is an example of a {bzl:obj}`py_test` target that gazelle would
189+
add when it encounters a file named `__test__.py`.
190+
191+
```starlark
192+
py_test(
193+
name = "build_file_generation_test",
194+
srcs = ["__test__.py"],
195+
main = "__test__.py",
196+
deps = [":build_file_generation"],
197+
)
198+
```
199+
200+
You can control the naming convention for test targets using the
201+
`# gazelle:python_test_naming_convention` directive.
202+
203+
204+
### Binaries
205+
206+
When a `__main__.py` file is encountered, this indicates the entry point
207+
of a Python program. A {bzl:obj}`py_binary` target will be created, named
208+
`[package]_bin`.
209+
210+
When no such entry point exists, Gazelle will look for a line like this in
211+
the top level in every module:
212+
213+
```python
214+
if __name == "__main__":
215+
```
216+
217+
Gazelle will create a {bzl:obj}`py_binary` target for every module with such
218+
a line, with the target name the same as the module name.
219+
220+
If the `# gazelle:python_generation_mode` directive is set to `file`, then
221+
instead of one {bzl:obj}`py_binary` target per module, Gazelle will create
222+
one {bzl:obj}`py_binary` target for each file with such a line, and the name
223+
of the target will match the name of the script.
224+
225+
:::{note}
226+
It's possible for another script to depend on a {bzl:obj}`py_binary` target
227+
and import from the {bzl:obj}`py_binary`'s scripts. This can have possible
228+
negative effects on Bazel analysis time and runfiles size compared to
229+
depending on a {bzl:obj}`py_library` target. The simplest way to avoid these
230+
negative effects is to extract library code into a separate script without a
231+
`main` line. Gazelle will then create a {bzl:obj}`py_library` target for
232+
that library code, and other scripts can depend on that {bzl:obj}`py_library`
233+
target.
234+
:::

0 commit comments

Comments
 (0)