If you want to know more about contributing on Setuptools, this is the place.
Table of Contents
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.
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.
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.
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.
setuptools uses towncrier
for changelog management.
To submit a change note about your PR, add a text file into the
changelog.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.
If you wish to sign your change, feel free to add
:user:`github-username` at the end (replace
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
misc 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
where the categories are:
change: Any backwards compatible code change
breaking: Any backwards-compatibility breaking change
doc: A change to the documentation
misc: Changes internal to the repo like CI, test and build changes
deprecation: 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.
Added a ``:user:`` role to Sphinx config -- by :user:`webknjaz`
Added ``towncrier`` for changelog managment -- by :user:`pganssle`
When pip is imported as part of a build, leave :py:mod:`distutils` patched -- by :user:`jaraco`
pyproject.toml for all available categories
To support running all code through CI, even lightweight contributions, the project employs Mergify to auto-merge pull requests tagged as auto-merge.
hub pull-request -l auto-merge to create such a pull request
from the command line after pushing a new branch.
The primary tests are run using tox. Make sure you have tox installed, and invoke it:
Under continuous integration, additional tests may be run. See the
.travis.yml file for full details on the tests run under Travis-CI.
To build the docs locally, use tox:
$ tox -e docs
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
pkg_resources/_vendor/vendored.txt and refreshed by way of
paver update_vendored (pavement.py).