@@ -11,26 +11,6 @@ To run the pipx executable from your source tree during development, run pipx fr
11
11
python src/pipx --version
12
12
```
13
13
14
- ## Pre-commit
15
-
16
- The use of [ pre-commit] ( https://pre-commit.com/ ) is recommended. It can show all and fix some lint errors before commit,
17
- saving you the trouble of finding out later that it failed CI Lint errors, and saving you from having to run
18
- ` nox -s lint ` separately.
19
-
20
- In the pipx git repository is a ` .pre-commit-config.yaml ` configuration file tailored just for pipx and its lint
21
- requirements. To use pre-commit in your clone of the pipx repository, you need to do the following ** one-time setup
22
- procedure** :
23
-
24
- 1 . Install pre-commit using ` pipx install pre-commit `
25
- 2 . In the top level directory of your clone of the pipx repository, execute ` pre-commit install `
26
-
27
- Afterwards whenever you commit in this repository, it will first run pipx's personalized lint checks. If it makes a fix
28
- to a file (e.g. using ` black ` or ` isort ` ), you will need to ` git add ` that file again before committing it again. If it
29
- can't fix your commit itself, it will tell you what's wrong, and you can fix it manually before re-adding the edited
30
- files and committing again.
31
-
32
- If for some reason you want to commit and skip running pre-commit, you can use the switch ` git commit --no-verify ` .
33
-
34
14
## Running Tests
35
15
36
16
### Setup
@@ -88,15 +68,18 @@ At the time of this writing, the output looks like this
88
68
* build_docs
89
69
- watch_docs
90
70
* build_man
91
- - pre_release
92
- - post_release
93
71
- create_test_package_list-3.12
94
72
- create_test_package_list-3.11
95
73
- create_test_package_list-3.10
96
74
- create_test_package_list-3.9
97
75
- create_test_package_list-3.8
98
76
```
99
77
78
+ ### Creating a developer environment
79
+
80
+ For developing the tool (and to attach to your IDE) we recommend creating a Python environment via
81
+ ` nox -s develop-3.12 ` , afterwards use the Python interpreter available under ` .nox/develop-3.12/bin/python ` .
82
+
100
83
### Unit Tests
101
84
102
85
To run unit tests in Python3.12, you can run
@@ -123,13 +106,13 @@ nox -s tests-3.12
123
106
124
107
Running the unit tests requires a directory ` .pipx_tests/package_cache ` to be populated from a fixed list of package
125
108
distribution files (wheels or source files). If you have network access, ` nox -s tests ` automatically makes sure this
126
- directory is populated (including downloading files if necessary) as a first step. Thus if you are running the tests
109
+ directory is populated (including downloading files if necessary) as a first step. Thus, if you are running the tests
127
110
with network access, you can ignore the rest of this section.
128
111
129
112
If, however, you wish to run tests offline without the need for network access, you can populate
130
113
` .pipx_tests/package_cache ` yourself manually beforehand when you do have network access.
131
114
132
- #### Populating the cache directory using nox
115
+ ### Populating the cache directory using nox
133
116
134
117
To populate ` .pipx_tests/package_cache ` manually using nox, execute:
135
118
@@ -140,19 +123,10 @@ nox -s refresh_packages_cache
140
123
This will sequence through available python executable versions to populate the cache directory for each version of
141
124
python on your platform.
142
125
143
- #### Populating the cache directory without nox
144
-
145
- An alternate method to populate ` .pipx_tests/package_cache ` without nox is to execute:
146
-
147
- ```
148
- mkdir -p .pipx_tests/package_cache
149
- python3 scripts/update_package_cache.py testdata/tests_packages .pipx_tests/package_cache
150
- ```
151
-
152
- You must do this using every python version that you wish to use to run the tests.
153
-
154
126
### Lint Tests
155
127
128
+ Linting is done via ` pre-commit ` , setting it up and running it can be done via ` nox ` by typing:
129
+
156
130
```
157
131
nox -s lint
158
132
```
@@ -181,16 +155,13 @@ Finally, check-in the new or modified list files in the directory `testdata/test
181
155
182
156
## Testing pipx on Continuous Integration builds
183
157
184
- When you push a new git branch, tests will automatically be run against your code as defined in
185
- ` .github/workflows/on-push.yml ` .
158
+ Upon opening pull requests GitHub Actions will automatically trigger.
186
159
187
160
## Building Documentation
188
161
189
162
` pipx ` autogenerate API documentation, and also uses templates.
190
163
191
- When updating pipx docs, make sure you are either modifying a file in the ` templates ` directory, or the ` docs `
192
- directory. If in the ` docs ` directory, make sure the file was not autogenerated from the ` templates ` directory.
193
- Autogenerated files have a note at the top of the file.
164
+ When updating pipx docs, make sure you are modifying the ` docs ` directory.
194
165
195
166
You can generate the documentation with
196
167
@@ -207,44 +178,12 @@ To preview changes, including live reloading, open another terminal and run
207
178
nox -s watch_docs
208
179
```
209
180
210
- ### Publishing Doc Changes to GitHub pages
211
-
212
- ```
213
- nox -s publish_docs
214
- ```
215
-
216
181
## Releasing New ` pipx ` Versions
217
182
218
- ### Pre-release
219
-
220
- First, make sure the changelog is complete. Next decide what the next version number will be. Then, from a clone of the
221
- main pypa pipx repo (not a fork) execute:
222
-
223
- ```
224
- nox -s pre_release
225
- ```
226
-
227
- Enter the new version number when asked. When the script is finished, check the diff it produces. If the diff looks
228
- correct, commit the changes as the script instructs, and push the result.
229
-
230
- The script will modify ` src/pipx/version.py ` to contain the new version, and also update the changelog
231
- (` docs/changelog.md ` ) to specify the new version.
232
-
233
- ### Release
234
-
235
- To publish to PyPI simply create a "published" release on Github. This will trigger Github workflows that both publish
236
- the pipx version to PyPI and publish the pipx documentation to the pipx website.
237
-
238
- ### Post-release
239
-
240
- From a clone of the main pypa pipx repo (not a fork) execute:
241
-
242
- ```
243
- nox -s post_release
244
- ```
183
+ To publish to PyPI simply create a "published" release on GitHub. This will trigger GitHub workflows that publishes:
245
184
246
- When the script is finished, check the diff it produces. If the diff looks correct, commit the changes as the script
247
- instructs, and push the result.
185
+ - the pipx version to PyPI,
186
+ - the documentation to readthedocs,
187
+ - the ` zipapp ` to the GitHub release created.
248
188
249
- This will update pipx's version in ` src/pipx/version.py ` by adding a suffix ` "dev0" ` for unreleased development, and
250
- will update the changelog to start a new section at the top entitled ` dev ` .
189
+ No need for any other pre or post publish steps.
0 commit comments