Contributing to proxy.py#

This document describes how contributors can participate and iterate quickly while maintaining the proxy.py project standards and guidelines.

Basic Guidelines#

  • Your pull request should NOT introduce any external dependency.

  • It is OK to use external dependencies within plugins.

Environment Setup#

Contributors must start proxy.py from source to verify and develop new features / fixes. See Run proxy.py from command line using repo source in README.md for usage instructions.

WARNING On macOS you must install Python using pyenv, as Python installed via homebrew tends to be problematic. See linked thread for more details.

Setup Git Hooks#

You SHOULD NOT avoid these steps. Git hooks will help catch test or linting errors locally without pushing to upstream. This will save you a lot of time and allow you to contribute and iterate faster.

Pre-commit hook ensures tests are passing.

  1. cd /path/to/proxy.py

  2. ln -s $(PWD)/git-pre-commit .git/hooks/pre-commit

Pre-push hook ensures lint and tests are passing.

  1. cd /path/to/proxy.py

  2. ln -s $(PWD)/git-pre-push .git/hooks/pre-push

Sending a Pull Request#

All pull requests are tested using GitHub actions.

See GitHub workflow for list of workflows.

Communication#

During the process of PR review, sometimes, you may get asked to update certain project configs. Example, a change in code introduced via your PR will result in a redundant lint guard. So we must make corresponding changes to ensure project health.

It’s highly recommended that you participate in maintaining a high code-quality standard. For any reason, if you are unable to address the requested changes, please communicate the same to the reviewer.

Thank you!!!

Contributing docs#

We use Sphinx to generate our docs website. You can trigger the process locally by executing:

$ tox -e build-docs

It is also integrated with Read The Docs that builds and publishes each commit to the main branch and generates live docs previews for each pull request.

The sources of the Sphinx documents use reStructuredText as a de-facto standard. But in order to make contributing docs more beginner-friendly, we have integrated MyST parser allowing us to also accept new documents written in an extended version of Markdown that supports using Sphinx directives and roles. Read the docs to learn more on how to use it.

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?#

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 MyST Markdown syntax for highlighting code (inline or block), linking parts of the docs or external sites. At the end, sign your change note by adding -- by {user}`github-username (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, bugfix, doc, misc etc., and add .md 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.

Examples for changelog entries adding to your Pull Requests#

File docs/changelog-fragments.d/112.doc.md:

Added a `{user}` role to Sphinx config -- by {user}`webknjaz`

File docs/changelog-fragments.d/105.feature.md:

Added the support for keyboard-authentication method
-- by {user}`Qalthos`

File docs/changelog-fragments.d/57.bugfix.md:

Fixed flaky SEGFAULTs in `pylibsshext.channel.Channel.exec_command()`
calls -- by {user}`ganeshrn`

Tip

See pyproject.toml for all available categories (tool.towncrier.type).