@@ -11,12 +11,12 @@ We welcome pull requests from cmd2 users and seasoned Python developers alike! F
11
11
12
12
Remember to feel free to ask for help by leaving a comment within the Issue.
13
13
14
- Working on your first pull request? You can learn how from the
14
+ Working on your first pull request? You can learn how from the
15
15
[ GitHub Docs] ( https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request ) .
16
16
17
17
###### If you've found a bug that is not on the board, [ follow these steps] ( ../README.md#found-a-bug ) .
18
18
19
- --------------------------------------------------------------------------------
19
+ ---
20
20
21
21
## Contribution guidelines
22
22
@@ -64,22 +64,21 @@ The tables below list all prerequisites along with the minimum required version
64
64
65
65
#### Additional prerequisites for developing cmd2
66
66
67
- | Prerequisite | Minimum Version | Purpose |
68
- | ----------------------------------------------------------------------| -----------------| ----------------------------|
69
- | [ codecov] ( http://doc.pytest.org/en/latest/ ) | ` 2.1.13 ` | Cover coverage reporting |
70
- | [ doc8] ( https://github.com/PyCQA/doc8 ) | ` 1.1.2 ` | Sphinx style checker |
71
- | [ invoke] ( https://www.pyinvoke.org/ ) | ` 2.2.0 ` | Command automation |
72
- | [ mypy] ( https://mypy-lang.org/ ) | ` 1.13.0 ` | Static type checker |
73
- | [ pytest] ( https://docs.pytest.org/en/stable/ ) | ` 3.0.6 ` | Unit and integration tests |
74
- | [ pytest-cov] ( http://doc.pytest.org/en/latest/ ) | ` 6.0.0 ` | Pytest code coverage |
75
- | [ pytest-mock] ( https://pypi.org/project/pytest-mock/ ) | ` 3.14.0 ` | Pytest mocker fixture |
76
- | [ sphinx] ( https://www.sphinx-doc.org/en/master/ ) | ` 8.1.3 ` | Documentation |
77
- | [ sphinx-autobuild] ( hhttps://pypi.org/project/sphinx-autobuild/ ) | ` 2024.10.3 ` | Rebuild docs on changes |
78
- | [ sphinx-rtd-theme] ( https://github.com/readthedocs/sphinx_rtd_theme ) | ` 3.0.1 ` | Sphinx theme for RTD |
79
- | [ ruff] ( https://github.com/astral-sh/ruff ) | ` 0.7.3 ` | Fast linter and formatter |
80
- | [ uv] ( https://github.com/astral-sh/uv ) | ` 0.5.1 ` | Python package management |
81
-
82
-
67
+ | Prerequisite | Minimum Version | Purpose |
68
+ | ------------------------------------------------------------------------------------------ | --------------- | --------------------------------- |
69
+ | [ codecov] ( http://doc.pytest.org/en/latest/ ) | ` 2.1.13 ` | Cover coverage reporting |
70
+ | [ invoke] ( https://www.pyinvoke.org/ ) | ` 2.2.0 ` | Command automation |
71
+ | [ griffe_typingdoc] ( https://github.com/mkdocstrings/griffe-typingdoc ) | ` 0.2.7 ` | mkdocstrings extension for typing |
72
+ | [ mypy] ( https://mypy-lang.org/ ) | ` 1.13.0 ` | Static type checker |
73
+ | [ pytest] ( https://docs.pytest.org/en/stable/ ) | ` 3.0.6 ` | Unit and integration tests |
74
+ | [ pytest-cov] ( http://doc.pytest.org/en/latest/ ) | ` 6.0.0 ` | Pytest code coverage |
75
+ | [ pytest-mock] ( https://pypi.org/project/pytest-mock/ ) | ` 3.14.0 ` | Pytest mocker fixture |
76
+ | [ mkdocs-include-markdown-plugin] ( https://pypi.org/project/mkdocs-include-markdown-plugin/ ) | ` 7.1.2 ` | MkDocs Plugin include MkDn |
77
+ | [ mkdocs-macros-plugin] ( https://mkdocs-macros-plugin.readthedocs.io/ ) | ` 1.3.7 ` | MkDocs Plugin for macros |
78
+ | [ mkdocs-material] ( https://squidfunk.github.io/mkdocs-material/ ) | ` 9.5.49 ` | Documentation |
79
+ | [ mkdocstrings[ python]] ( https://mkdocstrings.github.io/ ) | ` 0.27.0 ` | MkDocs Plugin for Python AutoDoc |
80
+ | [ ruff] ( https://github.com/astral-sh/ruff ) | ` 0.7.3 ` | Fast linter and formatter |
81
+ | [ uv] ( https://github.com/astral-sh/uv ) | ` 0.5.1 ` | Python package management |
83
82
84
83
If Python is already installed in your machine, run the following commands to validate the versions:
85
84
@@ -90,11 +89,12 @@ $ pip freeze | grep pyperclip
90
89
91
90
If your versions are lower than the prerequisite versions, you should update.
92
91
93
- If you do not already have Python installed on your machine, we recommend using [ uv] ( https://github.com/astral-sh/uv )
92
+ If you do not already have Python installed on your machine, we recommend using [ uv] ( https://github.com/astral-sh/uv )
94
93
for all of your Python needs because it is extremely fast, meets all Python installation and packaging needs, and works
95
- on all platforms (Windows, Mac, and Linux). You can install ` uv ` using instructions at the link above.
94
+ on all platforms (Windows, Mac, and Linux). You can install ` uv ` using instructions at the link above.
96
95
97
96
You can then install multiple versions of Python using ` uv ` like so:
97
+
98
98
``` sh
99
99
uv python install 3.9 3.10 3.11 3.12 3.13
100
100
```
@@ -148,31 +148,31 @@ Do this prior to every time you create a branch for a PR:
148
148
1 . Make sure you are on the ` master ` branch
149
149
150
150
> ``` sh
151
- > $ git status
152
- > On branch master
153
- > Your branch is up-to-date with ' origin/master' .
154
- > ` ` `
151
+ > $ git status
152
+ > On branch master
153
+ > Your branch is up-to-date with ' origin/master' .
154
+ > ` ` `
155
155
156
156
> If your aren' t on `master`, resolve outstanding files and commits and checkout the `master` branch
157
157
158
158
> ```sh
159
- > $ git checkout master
160
- > ```
159
+ > $ git checkout master
160
+ > ```
161
161
162
162
2. Do a pull with rebase against `upstream`
163
163
164
164
> ```sh
165
- > $ git pull --rebase upstream master
166
- > ```
165
+ > $ git pull --rebase upstream master
166
+ > ```
167
167
168
168
> This will pull down all of the changes to the official master branch, without making an additional commit in your
169
169
> local repo.
170
170
171
171
3. (_Optional_) Force push your updated master branch to your GitHub fork
172
172
173
173
> ```sh
174
- > $ git push origin master --force
175
- > ```
174
+ > $ git push origin master --force
175
+ > ```
176
176
177
177
> This will overwrite the master branch of your fork.
178
178
@@ -214,8 +214,8 @@ package from the source.
214
214
215
215
` cmd2 ` has support for using [ uv] ( https://github.com/astral-sh/uv ) for development.
216
216
217
- ` uv ` is single tool to replace ` pip ` , ` pip-tools ` , ` pipx ` , ` poetry ` , ` pyenv ` , ` twine ` , ` virtualenv ` , and more. ` cmd2 `
218
- contains configuration for using ` uv ` in it's ` pyproject.toml ` file which makes it extremely easy to setup a ` cmd2 `
217
+ ` uv ` is single tool to replace ` pip ` , ` pip-tools ` , ` pipx ` , ` poetry ` , ` pyenv ` , ` twine ` , ` virtualenv ` , and more. ` cmd2 `
218
+ contains configuration for using ` uv ` in it's ` pyproject.toml ` file which makes it extremely easy to setup a ` cmd2 `
219
219
development environment using ` uv ` .
220
220
221
221
To create a virtual environment and install everything needed for ` cmd2 ` development using ` uv ` , do the following
@@ -239,6 +239,7 @@ uv run examples/basic.py
239
239
```
240
240
241
241
Alternatively you can activate the virtual environment using the OS-specific command such as this on Linux or macOS:
242
+
242
243
``` sh
243
244
source .venv/bin/activate
244
245
```
@@ -317,7 +318,7 @@ primarily related to continuous integration and release deployment.
317
318
#### Changes to the documentation files
318
319
319
320
If you made changes to any file in the ` /docs ` directory, you need to build the
320
- Sphinx documentation and make sure your changes look good:
321
+ MkDocs documentation and make sure your changes look good:
321
322
322
323
``` sh
323
324
$ uv inv docs
@@ -338,7 +339,7 @@ served (usually [http://localhost:8000](http://localhost:8000)).
338
339
### Code Quality Checks
339
340
340
341
You should have some sort of [ PEP 8] ( https://www.python.org/dev/peps/pep-0008/ ) -based linting running in your editor or
341
- IDE or at the command line before you commit code. ` cmd2 ` uses [ ruff] ( https://github.com/astral-sh/ruff ) as part of
342
+ IDE or at the command line before you commit code. ` cmd2 ` uses [ ruff] ( https://github.com/astral-sh/ruff ) as part of
342
343
its continuous integration (CI) process for both linting and auto-formatting.
343
344
344
345
> Please do not ignore any linting errors in code you write or modify, as they are meant to ** help** you and to ensure a
@@ -441,7 +442,7 @@ nothing to commit, working directory clean
441
442
any outstanding files/commits and checkout master ` git checkout master `
442
443
443
444
2 . Create a branch off of ` master ` with git: `git checkout -B
444
- branch/name-here` ** Note:** Branch naming is important. Use a name like
445
+ branch/name-here` ** Note:** Branch naming is important. Use a name like
445
446
` fix/short-fix-description ` or ` feature/short-feature-description ` . Review
446
447
the [ Contribution Guidelines] ( #contribution-guidelines ) for more detail.
447
448
@@ -450,7 +451,7 @@ nothing to commit, working directory clean
450
451
4 . Check your ` git status ` to see unstaged files
451
452
452
453
5 . Add your edited files: ` git add path/to/filename.ext ` You can also do: `git
453
- add .` to add all unstaged files. Take care, though, because you can
454
+ add .` to add all unstaged files. Take care, though, because you can
454
455
accidentally add files you don't want added. Review your ` git status ` first.
455
456
456
457
6 . Commit your edits: ` git commit -m "Brief description of commit" ` . Do not add the issue number in the commit message.
@@ -483,17 +484,17 @@ how to do it.
483
484
4 . The title (also called the subject) of your PR should be descriptive of your
484
485
changes and succinctly indicate what is being fixed
485
486
486
- - ** Do not add the issue number in the PR title or commit message**
487
+ - ** Do not add the issue number in the PR title or commit message**
487
488
488
- - Examples: ` Add test cases for Unicode support ` ; ` Correct typo in overview documentation `
489
+ - Examples: ` Add test cases for Unicode support ` ; ` Correct typo in overview documentation `
489
490
490
491
5 . In the body of your PR include a more detailed summary of the changes you
491
492
made and why
492
493
493
- - If the PR is meant to fix an existing bug/issue, then, at the end of
494
- your PR's description, append the keyword ` closes ` and #xxxx (where xxxx
495
- is the issue number). Example: ` closes #1337 ` . This tells GitHub to
496
- close the existing issue if the PR is merged.
494
+ - If the PR is meant to fix an existing bug/issue, then, at the end of
495
+ your PR's description, append the keyword ` closes ` and #xxxx (where xxxx
496
+ is the issue number). Example: ` closes #1337 ` . This tells GitHub to
497
+ close the existing issue if the PR is merged.
497
498
498
499
6 . Indicate what local testing you have done (e.g. what OS and version(s) of Python did you run the
499
500
unit test suite with)
@@ -633,8 +634,8 @@ mostly automated. The manual steps are all git operations. Here's the checklist:
633
634
1 . Make sure all the unit tests pass with ` invoke pytest ` or ` py.test `
634
635
1 . Make sure latest year in ` LICENSE ` matches current year
635
636
1 . Make sure ` CHANGELOG.md ` describes the version and has the correct release date
636
- 1 . Add a git tag representing the version number using `` invoke tag x.y.z ` `
637
- * Where x, y, and z are all small non-negative integers
637
+ 1 . Add a git tag representing the version number using ` invoke tag x.y.z `
638
+ - Where x, y, and z are all small non-negative integers
638
639
1 . (Optional) Run ` invoke pypi-test ` to clean, build, and upload a new release to [ Test PyPi] ( https://test.pypi.org )
639
640
1 . Run ` invoke pypi ` to clean, build, and upload a new release to [ PyPi] ( https://pypi.org/ )
640
641
0 commit comments