# 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 GitHub Discussions, or the issue tracker (for specific issues).

Discussions about development happen on GitHub Discussions or the `setuptools` channel on PyPA Discord.

## Authoring Tickets

Before authoring any source code, it’s often prudent to file a ticket describing the motivation behind making changes. First search to see if a ticket already exists for your issue. If not, create one. Try to think from the perspective of the reader. Explain what behavior you expected, what you got instead, and what factors might have contributed to the unexpected behavior. In GitHub, surround a block of code or traceback with the triple backtick “```” so that it is formatted nicely.

Filing a ticket provides a forum for justification, discussion, and clarification. The ticket provides a record of the purpose for the change and any hard decisions that were made. It provides a single place for others to reference when trying to understand why the software operates the way it does or why certain changes were made.

Setuptools makes extensive use of hyperlinks to tickets in the changelog so that system integrators and other users can get a quick summary, but then jump to the in-depth discussion about any subject referenced.

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

### 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 to add a news fragment?

`setuptools` uses towncrier for changelog management. To submit a change note about your PR, add a text file into the `newsfragments/` folder, manually or by running `towncrier create`.

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 `-- 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`, `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 `<pr_number>.<category>.rst` pattern, where the categories are:

- `feature`: Any backwards compatible code change

- `bugfix`: A fix for broken behavior of a previous change

- `doc`: A change to the documentation

- `removal`: Any backwards-compatibility breaking change

- `misc`: Changes internal to the repo like CI, test and build changes

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 `newsfragments/2395.doc.1.rst`:

    Added a ``:user:`` role to Sphinx config -- by :user:`webknjaz`

File `newsfragments/1354.misc.rst`:

    Added ``towncrier`` for changelog management -- by :user:`pganssle`

File `newsfragments/2355.feature.rst`:

    When pip is imported as part of a build, leave :py:mod:`distutils`
    patched -- by :user:`jaraco`

Tip

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

## 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`.

All the dependencies specified in these files are “vendorized” using a simple Python script `tools/vendor.py`.

To refresh the dependencies, run the following command:

    $ tox -e vendor

## Code conventions and other practices

Setuptools utilizes the skeleton framework as a foundation for sharing reusable maintenance tasks across different projects in the ecosystem.

This also means that the project adheres to the same coding conventions and other practices described in the skeleton documentation.

Moreover, changes in the code base should be kept as compatible as possible to `skeleton` to avoid merge conflicts, or accidental regressions on periodical merges.

Finally, the `setuptools/_distutils` directory should not be modified directly when contributing to the `setuptools` project. Instead, this directory is maintained as a separated project in https://github.com/pypa/distutils, and periodically merged into `setuptools`.

## Type annotations

Most standards and best practices are enforced by Ruff’s `ANN2`, `FA`, `PYI`, `UP` and `YTT` rules.

Explicit return types have to be added for typed public functions whose parameters are all annotated. This is enforced by `ANN2`, but it’s worth noting that this is due to mypy inferring `Any` even for simple return types. Mypy also doesn’t count functions with missing parameter annotations as “typed”. (see python/mypy#4409, python/mypy#10149 and python/mypy#6646). Otherwise, return annotations can be omitted to reduce verbosity, especially for complex return types.

Instead of typing an explicit return type annotation as `Generator[..., None, None]`, we’ll prefer using an `Iterator` as it is more concise and conceptually easier to deal with. Returning a `Generator` with no `yield` type or `send` type can sometimes be considered as exposing implementation details. See Y058.

Avoid importing private type-checking-only symbols. These are often typeshed internal details and are not guaranteed to be stable. Importing from `_typeshed` or `typing_extensions` is fine, but if you find yourself importing the same symbol in `TYPE_CHECKING` blocks a lot, consider implementing an alias directly in `setuptools`.