Binary Distribution#

A specific kind of Built Distribution that contains compiled extensions.

Build Backend#

A library that takes a source tree or source distribution and builds a source distribution or wheel from it. The build is delegated to the backend by a frontend. All backends offer a standardized interface.

Examples of build backends are flit’s flit-core, hatch’s hatchling, Maturin, meson-python, scikit-build-core, and Setuptools.

Build Frontend#

A tool that users might run that takes arbitrary source trees or source distributions and builds source distributions or wheels from them. The actual building is delegated to each source tree’s build backend.

Examples of build frontends are pip and build.

Built Distribution#

A Distribution format containing files and metadata that only need to be moved to the correct location on the target system, to be installed. Wheel is such a format, whereas Source Distribution is not, in that it requires a build step before it can be installed. This format does not imply that Python files have to be precompiled (Wheel intentionally does not include compiled Python files). See Package Formats for more information.

Distribution Package#

A versioned archive file that contains Python packages, modules, and other resource files that are used to distribute a Release. The archive file is what an end-user will download from the internet and install.

A distribution package is more commonly referred to with the single words “package” or “distribution”, but this guide may use the expanded term when more clarity is needed to prevent confusion with an Import Package (which is also commonly called a “package”) or another kind of distribution (e.g. a Linux distribution or the Python language distribution), which are often referred to with the single term “distribution”. See Distribution package vs. import package for a breakdown of the differences.


A Built Distribution format introduced by Setuptools, which has been replaced by Wheel. For details, see What about eggs?.

Extension Module#

A Module written in the low-level language of the Python implementation: C/C++ for Python, Java for Jython. Typically contained in a single dynamically loadable pre-compiled file, e.g. a shared object (.so) file for Python extensions on Unix, a DLL (given the .pyd extension) for Python extensions on Windows, or a Java class file for Jython extensions.

Known Good Set (KGS)#

A set of distributions at specified versions which are compatible with each other. Typically a test suite will be run which passes all tests before a specific set of packages is declared a known good set. This term is commonly used by frameworks and toolkits which are comprised of multiple individual distributions.

Import Package#

A Python module which can contain other modules or recursively, other packages.

An import package is more commonly referred to with the single word “package”, but this guide will use the expanded term when more clarity is needed to prevent confusion with a Distribution Package which is also commonly called a “package”. See Distribution package vs. import package for a breakdown of the differences.


The basic unit of code reusability in Python, existing in one of two types: Pure Module, or Extension Module.

Package Index#

A repository of distributions with a web interface to automate package discovery and consumption.

Per Project Index#

A private or other non-canonical Package Index indicated by a specific Project as the index preferred or required to resolve dependencies of that project.


A library, framework, script, plugin, application, or collection of data or other resources, or some combination thereof that is intended to be packaged into a Distribution.

Since most projects create Distributions using either PEP 518 build-system, distutils or Setuptools, another practical way to define projects currently is something that contains a pyproject.toml,, or setup.cfg file at the root of the project source directory.

Python projects must have unique names, which are registered on PyPI. Each project will then contain one or more Releases, and each release may comprise one or more distributions.

Note that there is a strong convention to name a project after the name of the package that is imported to run that project. However, this doesn’t have to hold true. It’s possible to install a distribution from the project ‘foo’ and have it provide a package importable only as ‘bar’.

Pure Module#

A Module written in Python and contained in a single .py file (and possibly associated .pyc and/or .pyo files).

Python Packaging Authority (PyPA)#

PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at, host projects on GitHub and Bitbucket, and discuss issues on the distutils-sig mailing list and the Python Discourse forum.

Python Package Index (PyPI)#

PyPI is the default Package Index for the Python community. It is open to all Python developers to consume and distribute their distributions. is the domain name for the Python Package Index (PyPI). It replaced the legacy index domain name,, in 2017. It is powered by Warehouse.


The tool-agnostic Project specification file. Defined in PEP 518.


A snapshot of a Project at a particular point in time, denoted by a version identifier.

Making a release may entail the publishing of multiple Distributions. For example, if version 1.0 of a project was released, it could be available in both a source distribution format and a Windows installer distribution format.


A specification for a package to be installed. pip, the PYPA recommended installer, allows various forms of specification that can all be considered a “requirement”. For more information, see the pip install reference.

Requirement Specifier#

A format used by pip to install packages from a Package Index. For an EBNF diagram of the format, see Dependency specifiers. For example, “foo>=1.3” is a requirement specifier, where “foo” is the project name, and the “>=1.3” portion is the Version Specifier

Requirements File#

A file containing a list of Requirements that can be installed using pip. For more information, see the pip docs on Requirements Files.

The project specification files for distutils and Setuptools. See also pyproject.toml.

Source Archive#

An archive containing the raw source code for a Release, prior to creation of a Source Distribution or Built Distribution.

Source Distribution (or “sdist”)#

A distribution format (usually generated using python -m build --sdist) that provides metadata and the essential source files needed for installing by a tool like pip, or for generating a Built Distribution. See Package Formats for more information.

System Package#

A package provided in a format native to the operating system, e.g. an rpm or dpkg file.

Version Specifier#

The version component of a Requirement Specifier. For example, the “>=1.3” portion of “foo>=1.3”. Read the Version specifier specification for a full description of the specifiers that Python packaging currently supports. Support for this specification was implemented in Setuptools v8.0 and pip v6.0.

Virtual Environment#

An isolated Python environment that allows packages to be installed for use by a particular application, rather than being installed system wide. For more information, see the section on Creating Virtual Environments.


The standard Built Distribution format. See Package Formats for more information.

Working Set#

A collection of distributions available for importing. These are the distributions that are on the sys.path variable. At most, one Distribution for a project is possible in a working set.