This PEP proposes that the Installing Python Modules guide in Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of pip as the default installer for Python packages, and that appropriate technical changes be made in Python 3.4 to provide pip by default in support of that recommendation.

There are two related, but distinct rationales for the proposal in this PEP. The first relates to the experience of new users, while the second relates to better enabling the evolution of the broader Python packaging ecosystem.

Improving the new user experience Currently, on systems without a platform package manager and repository, installing a third-party Python package into a freshly installed Python requires first identifying an appropriate package manager and then installing it. Even on systems that do have a platform package manager, it is unlikely to include every package that is available on the Python Package Index, and even when a desired third-party package is available, the correct name in the platform package manager may not be clear. This means that, to work effectively with the Python Package Index ecosystem, users must know which package manager to install, where to get it, and how to install it. The effect of this is that third-party Python projects are currently required to choose from a variety of undesirable alternatives: Assume the user already has a suitable cross-platform package manager installed.

Duplicate the instructions and tell their users how to install the package manager.

Completely forgo the use of dependencies to ease installation concerns for their users. All of these available options have significant drawbacks. If a project simply assumes a user already has the tooling then beginning users may get a confusing error message when the installation command doesn't work. Some operating systems may ease this pain by providing a global hook that looks for commands that don't exist and suggest an OS package they can install to make the command work, but that only works on systems with platform package managers that include a package that provides the relevant cross-platform installer command (such as many major Linux distributions). No such assistance is available for Windows and Mac OS X users, or more conservative Linux distributions. The challenges of dealing with this problem for beginners (who are often also completely new to programming, the use of command line tools and editing system environment variables) are a regular feature of feedback the core Python developers receive from professional educators and others introducing new users to Python. If a project chooses to duplicate the installation instructions and tell their users how to install the package manager before telling them how to install their own project then whenever these instructions need updates they need updating by every project that has duplicated them. This is particular problematic when there are multiple competing installation tools available, and different projects recommend different tools. This specific problem can be partially alleviated by strongly promoting pip as the default installer and recommending that other projects reference pip's own bootstrapping instructions rather than duplicating them. However the user experience created by this approach still isn't particularly good (although there is an effort under way to create a combined Windows installer for pip and its dependencies that should improve matters on that platform, and Mac OS X and *nix platforms generally have wget and hence the ability to easily download and run the bootstrap scripts from the command line). The projects that have decided to forgo dependencies altogether are forced to either duplicate the efforts of other projects by inventing their own solutions to problems or are required to simply include the other projects in their own source trees. Both of these options present their own problems either in duplicating maintenance work across the ecosystem or potentially leaving users vulnerable to security issues because the included code or duplicated efforts are not automatically updated when upstream releases a new version. By officially recommending and providing by default a specific cross-platform package manager it will be easier for users trying to install these third-party packages as well as easier for the people distributing them as they should now be able to safely assume that most users will have the appropriate installation tools available (or access to clear instructions on how to obtain them). This is expected to become more important in the future as the Wheel package format (deliberately) does not have a built in "installer" in the form of setup.py so users wishing to install from a wheel file will want an installer even in the simplest cases. Reducing the burden of actually installing a third-party package should also decrease the pressure to add every useful module to the standard library. This will allow additions to the standard library to focus more on why Python should have a particular tool out of the box, and why it is reasonable for that package to adopt the standard library's 18-24 month feature release cycle, instead of using the general difficulty of installing third-party packages as justification for inclusion. Providing a standard installation system also helps with bootstrapping alternate build and installer systems, such as zc.buildout , hashdist and conda . So long as pip install <tool> works, then a standard Python-specific installer provides a reasonably secure, cross platform mechanism to get access to these utilities.

Enabling the evolution of the broader Python packaging ecosystem As no new packaging standard can achieve widespread adoption without a transition strategy that covers the versions of Python that are in widespread current use (rather than merely future versions, like most language features), the change proposed in this PEP is considered a necessary step in the evolution of the Python packaging ecosystem The broader community has embraced the Python Package Index as a mechanism for distributing and installing Python software, but the different concerns of language evolution and secure software distribution mean that a faster feature release cycle that encompasses older versions is needed to properly support the latter. In addition, the core CPython development team have the luxury of dropping support for earlier Python versions well before the rest of the community, as downstream commercial redistributors pick up the task of providing support for those versions to users that still need it, while many third party libraries maintain compatibility with those versions as long as they remain in widespread use. This means that the current setup.py install based model for package installation poses serious difficulties for the development and adoption of new packaging standards, as, depending on how a project writes their setup.py file, the installation command (along with other operations) may end up invoking the standard library's distutils package. As an indicator of how this may cause problems for the broader ecosystem, consider that the feature set of distutils in Python 2.6 was frozen in June 2008 (with the release of Python 2.6b1), while the feature set of distutils in Python 2.7 was frozen in April 2010 (with the release of Python 2.7b1). By contrast, using a separate installer application like pip (which ensures that even setup.py files that invoke distutils directly still support the new packaging standards) makes it possible to support new packaging standards in older versions of Python, just by upgrading pip (which receives new feature releases roughly every 6 months). The situation on older versions of Python is further improved by making it easier for end users to install and upgrade newer build systems like setuptools or improved PyPI upload utilities like twine . It is not coincidental that this proposed model of using a separate installer program with more metadata heavy and less active distribution formats matches that used by most operating systems (including Windows since the introduction of the installer service and the MSI file format), as well as many other language specific installers. For Python 2.6, this compatibility issue is largely limited to various enterprise Linux distributions (and their downstream derivatives). These distributions often have even slower update cycles than CPython, so they offer full support for versions of Python that are considered "security fix only" versions upstream (and sometimes may even be to the point where the core development team no longer support them at all - you can still get commercial support for Python 2.3 if you really need it!). In practice, the fact that tools like wget and curl are readily available on Linux systems, that most users of Python on Linux are already familiar with the command line, and that most Linux distributions ship with a default configuration that makes running Python scripts easy, means that the existing pip bootstrapping instructions for any *nix system are already quite straightforward. Even if pip isn't provided by the system package manager, then using wget or curl to retrieve the bootstrap script from www.pip-installer.org and then running it is just a couple of shell commands that can easily be copied and pasted as necessary. Accordingly, for any version of Python on any *nix system, the need to bootstrap pip in older versions isn't considered a major barrier to adoption of new packaging standards, since it's just one more small speedbump encountered by users of these long term stable releases. For *nix systems, this PEP's formal endorsement of pip as the preferred default packaging tool is seen as more important than the underlying technical details involved in making pip available by default, since it shifts the nature of the conversation between the developers of pip and downstream repackagers of both pip and CPython. For Python 2.7, on the other hand, the compatibility issue for adopting new metadata standards is far more widespread, as it affects the python.org binary installers for Windows and Mac OS X, as well as even relatively fast moving *nix platforms. Firstly, and unlike Python 2.6, Python 2.7 is still a fully supported upstream version, and will remain so until the release of Python 2.7.9 (currently scheduled for May 2015), at which time it is expected to enter the usual "security fix only" mode. That means there are at least another 19 months where Python 2.7 is a deployment target for Python applications that enjoys full upstream support. Even after the core development team switches 2.7 to security release only mode in 2015, Python 2.7 will likely remain a commercially supported legacy target out beyond 2020. While Python 3 already presents a compelling alternative over Python 2 for new Python applications and deployments without an existing investment in Python 2 and without a dependency on specific Python 2 only third party modules (a set which is getting ever smaller over time), it is going to take longer to create compelling business cases to update existing Python 2.7 based infrastructure to Python 3, especially in situations where the culture of automated testing is weak (or nonexistent), making it difficult to effectively use the available migration utilities. While this PEP only proposes documentation changes for Python 2.7, once pip has a Windows installer available, a separate PEP will be created and submitted proposing the creation and distribution of aggregate installers for future CPython 2.7 maintenance releases that combine the CPython, pip and Python Launcher for Windows installers into a single download (the separate downloads would still remain available - the aggregate installers would be provided as a convenience, and as a clear indication of the recommended operating environment for Python in Windows systems).