Contributing to cheroot#
Make sure you read the README. Also ensure you set up pre-commit utility correctly and tests pass in GitHub Actions CI/CD workflows.
Submitting Pull Requests#
If you’re changing the structure of the repository please create an issue first. Don’t forget to write appropriate test cases, add them into CI process if applicable and make the GitHub Actions CI/CD build pass.
Sync (preferably rebase) your feature branch with upstream regularly to make us able to merge your PR seamlessly.
Submitting bug reports#
Make sure you are on latest changes and that you re-ran this command tox
after updating your local repository. If you can, please provide more
information about your environment such as browser, operating system,
python version, and any other related software versions. It is also helpful to
post a markdown snippet demonstrating minimum reproducible example of an issue.
Also#
See Contributing in the CherryPy docs.
First-time setup#
You need to install Python 3 which is required for building docs. For example, Python 3.11.
Then, create and activate a virtual environment. And install tox.
Please, identify yourself:
$ git config --global user.name "firstname lastname" $ git config --global user.email yourname@example.com
Use the address bound to your GitHub account so that the commits would be linked to your profile.
Choose an editor for Git:
$ git config --global core.editor vim
Create and log in to a GitHub account
Fork Cheroot to your GitHub account by clicking the Fork button
Clone your fork locally:
$ git clone https://github.com/{username}/cheroot $ cd cheroot
To create a new branch and switch to it:
$ git checkout -b patch/some_fix
Write your code#
Please, use PEP 8
Once you finished coding, you are recommended to do the following steps:#
Run tests with tox
Run one test with Python3.11:
$ tox -e py311 -- cheroot/test/test_name.py
``tox`` — Run all tests using the Python version where Python Runtime Services
command
currently points to which is specified in tox
settings:
envlist = python
minversion = 3.21.0
Run linters and all tests against several Python interpreters:
$ tox -e pre-commit,py310,py37 # etc.
Run the pre-commit linting suite:
$ tox -e pre-commit
git add your files
Write good commit messages when checking in your changes to Git
Building the docs#
To build the docs from a checked out source, run:
$ tox -e build-docs
Open the documentation:
$ xdg-open build/html/index.html
$ open build/html/index.html
Please, open build/html/index.html
in your browser.
Also, one can serve docs using a built-in static files server. This is preferable because of possible CSRF issues.:
$ python3 -m http.server --directory build/html/ 8000
After that, you can open http://localhost:8000/ in your browser.
Read more about Sphinx.
Adding change notes with your PRs#
It is very important to maintain a log for news of how updating to the new version of the software will affect end-users. This is why we enforce collection of the change fragment files in pull requests as per Towncrier philosophy.
The idea is that when somebody makes a change, they must record the bits that would affect end-users only including information that would be useful to them. Then, when the maintainers publish a new release, they’ll automatically use these records to compose a change log for the respective version. It is important to understand that including unnecessary low-level implementation related details generates noise that is not particularly useful to the end-users most of the time. And so such details should be recorded in the Git history rather than a changelog.
Alright! So how do I add a news fragment?#
Cheroot uses towncrier
for changelog management.
To submit a change note about your PR, add a text file into the
docs/changelog-fragments.d/
folder. It should contain an
explanation of what applying this PR will change in the way
end-users interact with the project. One sentence is usually
enough but feel free to add as many details as you feel necessary
for the users to understand what it means.
Use the past tense for the text in your fragment because,
combined with others, it will be a part of the “news digest”
telling the readers what changed in a specific version of
the library since the previous version. You should also use
reStructuredText syntax for highlighting code (inline or block),
linking parts of the docs or external sites.
However, you do not need to reference the issue or PR numbers here
as towncrier will automatically add a reference to all of the
affected issues when rendering the news file.
If you wish to sign your change, feel free to add -- by
:user:`github-username`
at the end (replace github-username
with your own!).
Finally, name your file following the convention that Towncrier
understands: it should start with the number of an issue or a
PR followed by a dot, then add a patch type, like feature
,
doc
, contrib
etc., and add .rst
as a suffix. If you
need to add more than one fragment, you may add an optional
sequence number (delimited with another period) between the type
and the suffix.
In general the name will follow <pr_number>.<category>.rst
pattern,
where the categories are:
bugfix
: A bug fix for something we deemed an improper undesired behavior that got corrected in the release to match pre-agreed expectations.feature
: A new behavior, public APIs. That sort of stuff.deprecation
: A declaration of future API removals and breaking changes in behavior.breaking
: When something public gets removed in a breaking way. Could be deprecated in an earlier release.doc
: Notable updates to the documentation structure or build process.packaging
: Notes for downstreams about unobvious side effects and tooling. Changes in the test invocation considerations and runtime assumptions.contrib
: Stuff that affects the contributor experience. e.g. Running tests, building the docs, setting up the development environment.misc
: Changes that are hard to assign to any of the above categories.
A pull request may have more than one of these components, for example a code change may introduce a new feature that deprecates an old feature, in which case two fragments should be added. It is not necessary to make a separate documentation fragment for documentation changes accompanying the relevant code changes.
Examples for adding changelog entries to your Pull Requests#
File docs/changelog-fragments.d/77.doc.rst
:
Fixed a WSGI documentation example to support Python 3
-- by :user:`jaymcgrath`.
File docs/changelog-fragments.d/384.feature.rst
(could be symlinked
to docs/changelog-fragments.d/384.doc.rst
so it shows up in several
changelog sections, and to docs/changelog-fragments.d/385.feature.rst
and docs/changelog-fragments.d/406.feature.rst
referencing several
pull requests at once):
Exposed type stubs with annotations for public API -- by :user:`kasium`.
File docs/changelog-fragments.d/359.bugfix.rst
:
Fixed a regression from :pr:`199` that made the worker threads exit on
invalid connection attempts and could make the whole server unresponsive
once there was no workers left -- by :user:`cameronbrunner`.
Tip
See towncrier.toml
for all available categories
(tool.towncrier.type
).