You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/contributing.md
+74-22
Original file line number
Diff line number
Diff line change
@@ -12,8 +12,7 @@ If you have an idea for a modification or feature, it's probably best to raise a
12
12
13
13
Everyone contributing to the cibuildwheel project is expected to follow the [PSF Code of Conduct](https://github.com/pypa/.github/blob/main/CODE_OF_CONDUCT.md).
14
14
15
-
Design Goals
16
-
------------
15
+
## Design Goals
17
16
18
17
-`cibuildwheel` should wrap the complexity of wheel building.
19
18
- The user interface to `cibuildwheel` is the build script (e.g. `.travis.yml`). Feature additions should not increase the complexity of this script.
@@ -33,41 +32,94 @@ We're not responsible for errors in those tools, for fixing errors/crashes there
33
32
34
33
So, if we can, I'd like to improve the experience on errors as well. In [this](https://github.com/pypa/cibuildwheel/issues/139) case, it takes a bit of knowledge to understand that the Linux builds are happening in a different OS via Docker, that the linked symbols won't match, that auditwheel will fail because of this. A problem with how the tools fit together, instead of the tools themselves.
35
34
36
-
Maintainer notes
37
-
----------------
35
+
## Development
38
36
39
-
### Nox support
37
+
### Running the tests
40
38
41
-
Most developer tasks have a nox interface. This allows you to very simply run tasks without worrying about setting up a development environment (as shown below). This is a slower than setting up a development environment and reusing it, but has the (important) benefit of being highly reproducible; an earlier run does not affect a current run, or anything else on your machine.
39
+
When making a change to the codebase, you can run tests locally for quicker feedback than the CI runs on a PR. You can [run them directly](#making-a-venv), but the easiest way to run tests is using [nox](https://nox.thea.codes/).
42
40
43
-
Install [nox](https://nox.thea.codes); homebrew is recommend on macOS, otherwise, pipx is a great choice - in fact, you can use `pipx run nox` and avoid installing completely.
41
+
You can run all the tests locally by doing:
44
42
45
-
You can see a list of sessions by typing `nox -l`; here are a few common ones:
43
+
```bash
44
+
nox -s tests
45
+
```
46
46
47
-
```console
48
-
nox -s lint # Run the linters (default)
49
-
nox -s tests # Run the tests (default)
50
-
nox -s docs -- serve # Build and serve the documentation
51
-
nox -s build # Make SDist and wheel
47
+
However, because this takes a while, you might prefer to be more specific.
48
+
49
+
#### Unit tests
50
+
51
+
To run the project's unit tests, do:
52
+
53
+
```bash
54
+
nox -s tests -- unit_test
52
55
```
53
56
54
-
More advanced users can run the update scripts. `update_pins` should work directly, but `update_constraints` needs all versions of Python installed. If you don't want to do that locally, a fast way to run it to use docker to run nox:
57
+
There are a few custom options to enable different parts of the test suite - check `nox -s tests -- unit_test --help` for details.
55
58
56
-
```console
57
-
docker run --rm -itv $PWD:/src -w /src quay.io/pypa/manylinux_2_24_x86_64:latest pipx run nox -s update_constraints
59
+
If you're calling this a lot, you might consider using the `-r` or `-R` arguments to nox to make it a bit faster. This calls pytest under the hood, so to target a specific test, use pytest's `-k` option after the `--` above to select a specific test.
60
+
61
+
#### Integration tests
62
+
63
+
To run the project's integration tests, do:
64
+
65
+
```bash
66
+
nox -s tests -- test
58
67
```
59
68
60
-
### Local testing
69
+
The integration test suite is big - it can take more than 30 minutes to run the whole thing.
61
70
62
-
You should run:
71
+
Because it takes such a long time, normally you'd choose specific tests to run locally, and rely on the project's CI for the rest. Use pytest's `-k` option to choose specific tests. You can pass a test name or a filename, it'll run everything that matches.
63
72
64
-
```console
65
-
python3 -m venv venv
66
-
. venv/bin/activate
73
+
```bash
74
+
nox -s tests -- test -k <test_name_or_filename>
75
+
# e.g.
76
+
nox -s tests -- test -k before_build
77
+
```
78
+
79
+
A few notes-
80
+
81
+
- Because they run inside a container, Linux tests can run on all platforms where Docker is installed, so they're convenient for running integration tests locally. Set CIBW_PLATFORM to do this: `CIBW_PLATFORM=linux nox -s tests -- test`.
82
+
83
+
- Running the macOS integration tests requires _system installs_ of Python from python.org for all the versions that are tested. We won't attempt to install these when running locally, but you can do so manually using the URL in the error message that is printed when the install is not found.
84
+
85
+
#### Making a venv
86
+
87
+
More advanced users might prefer to invoke pytest directly-
88
+
89
+
```bash
90
+
python3 -m venv .venv
91
+
source .venv/bin/activate
67
92
pip install -e .[dev]
93
+
# run the unit tests
94
+
pytest unit_test
95
+
# run the whole integration test suite
96
+
pytest test
97
+
# run a specific integration test
98
+
pytest test -k test_build_frontend_args
99
+
# run a specific integration test on a different platform
100
+
CIBW_PLATFORM=linux pytest test -k test_build_frontend_args
101
+
```
102
+
103
+
### Linting, docs
104
+
105
+
Most developer tasks have a nox interface. This allows you to very simply run tasks without worrying about setting up a development environment (as shown below). This is a slower than setting up a development environment and reusing it, but has the (important) benefit of being highly reproducible; an earlier run does not affect a current run, or anything else on your machine.
106
+
107
+
You can see a list of sessions by typing `nox -l`; here are a few common ones:
108
+
109
+
```console
110
+
nox -s lint # Run the linters (default)
111
+
nox -s tests [-- PYTEST-ARGS] # Run the tests (default)
112
+
nox -s docs -- serve # Build and serve the documentation
113
+
nox -s build # Make SDist and wheel
114
+
```
115
+
116
+
More advanced users can run the update scripts. `update_pins` should work directly, but `update_constraints` needs all versions of Python installed. If you don't want to do that locally, a fast way to run it to use docker to run nox:
117
+
118
+
```console
119
+
docker run --rm -itv $PWD:/src -w /src quay.io/pypa/manylinux_2_24_x86_64:latest pipx run nox -s update_constraints
0 commit comments