- 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.
- 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.
- 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 distutil’s 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).
- 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».
- 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».
- Package Index#
A repository of distributions with a web interface to automate package discovery and consumption.
- Per Project Index#
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, setup.py, or setup.cfg file at the root of the project source directory.
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
.pyfile (and possibly associated
- Python Packaging Authority (PyPA)#
PyPA is a working group that maintains many of the relevant projects in Python packaging. They maintain a site at pypa.io, host projects on GitHub and Bitbucket, and discuss issues on the distutils-sig mailing list and the Python Discourse forum.
- Python Package Index (PyPI)#
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 the pkg_resources.Requirement entry in the Setuptools docs. 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#
- Source Archive#
- 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.
- 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.
- Working Set#