Developer’s Guide for Setuptools¶
If you want to know more about contributing on Setuptools, this is the place.
Recommended Reading¶
Please read How to write the perfect pull request for some tips on contributing to open source projects. Although the article is not authoritative, it was authored by the maintainer of Setuptools, so reflects his opinions and will improve the likelihood of acceptance and quality of contribution.
Project Management¶
Setuptools is maintained primarily in GitHub at this home. Setuptools is maintained under the Python Packaging Authority (PyPA) with several core contributors. All bugs for Setuptools are filed and the canonical source is maintained in GitHub.
User support and discussions are done through the issue tracker (for specific) issues, through the distutils-sig mailing list, or on IRC (Freenode) at #pypa.
Discussions about development happen on the distutils-sig mailing list or on Gitter.
Making a pull request¶
When making a pull request, please include a short summary of the changes and a reference to any issue tickets that the PR is intended to solve. All PRs with code changes should include tests. All changes should include a changelog entry.
setuptools
uses towncrier
for changelog management, so when making a PR, please add a news fragment in the
changelog.d/
folder. Changelog files are written in reStructuredText and
should be a 1 or 2 sentence description of the substantive changes in the PR.
They should be named <pr_number>.<category>.rst
, where the categories are:
change
: Any backwards compatible code changebreaking
: Any backwards-compatibility breaking changedoc
: A change to the documentationmisc
: Changes internal to the repo like CI, test and build changesdeprecation
: For deprecations of an existing feature or behavior
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. See the following for an example news fragment:
$ cat changelog.d/1288.change.rst
Add support for maintainer in PKG-INFO
Auto-Merge Requests¶
To support running all code through CI, even lightweight contributions, the project employs Mergify to auto-merge pull requests tagged as auto-merge.
Use hub pull-request -l auto-merge
to create such a pull request
from the command line after pushing a new branch.
Testing¶
The primary tests are run using tox. Make sure you have tox installed, and invoke it:
$ tox
Under continuous integration, additional tests may be run. See the
.travis.yml
file for full details on the tests run under Travis-CI.
Semantic Versioning¶
Setuptools follows semver
.
Building Documentation¶
Setuptools relies on the Sphinx system for building documentation. The published documentation is hosted on Read the Docs.
To build the docs locally, use tox:
$ tox -e docs
Vendored Dependencies¶
Setuptools has some dependencies, but due to bootstrapping issues, those dependencies
cannot be declared as they won’t be resolved soon enough to build
setuptools from source. Eventually, this limitation may be lifted as
PEP 517/518 reach ubiquitous adoption, but for now, Setuptools
cannot declare dependencies other than through
setuptools/_vendor/vendored.txt
and
pkg_resources/_vendor/vendored.txt
and refreshed by way of
paver update_vendored
(pavement.py).