| Page Status: | Complete |
|---|---|
| Last Reviewed: | 2014-08-25 |
Summaries for the currently relevant PEPs in the space of Python installation and packaging.
| PEP Link: | |
|---|---|
| PEP Status: | Accepted |
| Summary: | Describes a new .dist-info directory structure and system of metadata to be used when installing distributions. |
| User Impact: | This has very little implication for users, except to be aware of the format if they go hunting through their site-packages. Note PEP426 will likely spawn a child PEP that updates this to use a json-based system of metadata. |
| Implementation: | Currently, the bdist_wheel extension from the wheel project creates distributions using this structure, and setuptools and pip are equipped to manage distributions installed in this way. There is also an implementation in distlib. |
| PEP Link: | |
|---|---|
| PEP Status: | Accepted |
| Summary: | Specifies a tagging system to use in Built Distribution file names. The motivation for the system was to tag wheel distributions, which are covered in PEP427 Note A revision to this PEP is likely due to simple tags like “linux_x86_64” not handling the variation within linux platforms. Because of this, PyPI currently blocks uploading linux platform-specific wheels and pip won’t install linux platform-specific wheels from PyPI. |
| User Impact: | As wheels become more common, users will notice the new tagging scheme in wheel filenames. |
| Implementation: | The bdist_wheel setuptools extensions generates wheels using this scheme, and pip’s wheel installer understands the scheme as of v1.4. The wheel builder in distlib also implements this scheme. |
| PEP Link: | |
|---|---|
| PEP Status: | Accepted |
| Summary: | Specifies a Built Distribution format, that is based on, but modernizes the Egg format. Wheel filenames conform to PEP425 Note PEP426 will likely spawn a child PEP that updates this to use a json-based system of metadata. |
| User Impact: | Built distributions are fast to install. |
| Implementation: | The bdist_wheel setuptools extension (available from wheel) generates wheels, and pip supports installing wheels as of v1.4. There is also an implementation in distlib, which allows both building wheels and installing from wheels. |
| PEP Link: | PEP438 |
|---|---|
| PEP Status: | Accepted |
| Summary: | Specifies a two-step plan to phase out the primary use of external download links on PyPI, for the sake of security and installation speed. |
| User Impact: | pip (as of v1.5) will be faster and more secure by default. |
| Implementation: | Both pip and PyPI made changes during 2013 to implement this PEP. |
| PEP Link: | PEP453 |
|---|---|
| PEP Status: | Accepted |
| Summary: | Proposes the inclusion of a method for explicitly bootstrapping pip as the default package manager for Python. |
| User Impact: | pip will be available in some Python installations without users having to install it. |
| Implementation: | The goal is to have this for Python 3.4. PEP453 includes an integration timeline. |
| PEP Link: | PEP426 |
|---|---|
| PEP Status: | Draft |
| Summary: | Specifies version 2.0 of the metadata format. Version 1.0 is specified in PEP241. Version 1.1 is specified in PEP314. Version 1.2 is specified in PEP345. This is a work in progress, and represents a major upgrade to the Packaging ecosystem. PEP440 is a child of this PEP, and more PEPs are likely to grow out of this, as it evolves. |
| User Impact: | When this is accepted, users themselves will not do anything to adopt the new system, but rather projects like pip, setuptools, and PyPI will make changes to conform to it, and then surface new features and functionality to users that are based on top of the new system. |
| Implementation: | Most of the PEP is implemented in distlib, including the dependency metadata. Since the PEP is still in flux, the distlib implementation lags behind the most recent PEP changes, but most of the functionality in the PEP is covered. |
| PEP Link: | PEP440 |
|---|---|
| PEP Status: | Accepted |
| Summary: | Specifies a versioning system for Python projects that goes along with PEP426, and replaces PEP386. This system will be mostly consistent with how most people version their projects today. |
| User Impact: | Users will have a clear specification for what’s proper versioning for Python projects. |
| Implementation: | distlib has version classes that understand PEP440, and pip relies on distlib‘s implementation in specific cases. pip also has a work-in-progress PR that implements PEP440. |
| PEP Link: | PEP458 |
|---|---|
| PEP Status: | Draft |
| Summary: | Specifies an integration of PyPI with the “The Update Framework” (TUF). |
| User Impact: | pip will be more secure against various types of security attacks on PyPI and protect users against them. |
| Implementation: | Nothing at this time. |
| PEP Link: | PEP470 |
|---|---|
| PEP Status: | Draft |
| Summary: | PyPI would no longer support projects configuring external hosting links that pip crawls and installs from automatically. Projects would be allowed to configure external index links, but pip would never install from them automatically, but instead, only give users an informational message about what command they would use to do the install. This PEP effectively reverts PEP438. |
| User Impact: | This would obsolete pip’s --allow-external and --allow-unverified links, because PyPI itself wouldn’t contain external or unverified links. |
| Implementation: | Nothing at this time. |