diff --git a/pep-0453.txt b/pep-0453.txt index b70044949..5ee45a6e1 100644 --- a/pep-0453.txt +++ b/pep-0453.txt @@ -17,8 +17,8 @@ Abstract This PEP proposes that the `pip`_ package manager be made available by default when installing CPython and when creating virtual environments -using the standard library's ``venv`` module (including via the -``pyvenv`` command line utility). +using the standard library's ``venv`` module via the ``pyvenv`` command line +utility). To clearly demarcate development responsibilities, and to avoid inadvertently downgrading ``pip`` when updating CPython, the proposed @@ -64,12 +64,12 @@ 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 +* 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. @@ -79,7 +79,7 @@ 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 (such as major Linux -distributions). No such assistance is availabe for Windows and +distributions). No such assistance is available for Windows and Mac OS X users. The challenges of dealing with this problem are a regular feature of feedback the core Python developers receive from professional educators and others introducing new users to Python. @@ -154,7 +154,7 @@ for a tool bundled with CPython. Other tools like ``zc.buildout`` and ``conda`` are more ambitious in their aims (and hence substantially better than ``pip`` at handling external binary dependencies), so it makes sense for the Python ecosystem to treat -them more like platform package managers to interoperate with rather than +them more like platform package managers to inter operate with rather than as the default cross-platform installation tool. This relationship is similar to that between ``pip`` and platform package management systems like ``apt`` and ``yum`` (which are also designed to handle arbitrary @@ -210,7 +210,7 @@ Implementation strategy To ensure there is no need for network access when installing Python or creating virtual environments, the ``extractpip`` module will, as an implementation detail, include a complete private copy of pip and its -dependencies which will be used to extra pip and install it into the target +dependencies which will be used to extract pip and install it into the target environment. It is important to stress that this private copy of pip is *only* an implementation detail and it should *not* be relied on or assumed to exist beyond the public capabilities exposed through the @@ -225,7 +225,7 @@ to include private copies of ``pip`` and ``setuptools`` as wheel files contact PyPI (instead installing directly from the private wheel files. Rather than including separate code to handle the bootstrapping, the -``extractpip`` module will manipulating sys.path appropriately to allow +``extractpip`` module will manipulate sys.path appropriately to allow the wheel files to be used to install themselves, either into the current Python installation or into a virtual environment (as determined by the options passed to the bootstrap command). @@ -267,11 +267,15 @@ The proposed ``extractpip`` module API consists of the following two functions:: def version(): - """Returns a string specifying the bootstrapped version of pip""" + """ + Returns a string specifying the bundled version of pip. + """ def bootstrap(root=None, upgrade=False, user=False, verbosity=0): - """Bootstrap pip into the current Python installation (or the given - root directory)""" + """ + Bootstrap pip into the current Python installation (or the given root + directory). + """ Invocation from the CPython installers @@ -390,7 +394,7 @@ This PEP proposes that, if pip still requires it as a dependency, to the private copy of ``extractpip``). ``python -m extractpip`` will then install the private copy in addition to installing ``pip`` itself. -However, this behaviour is officially considered an implementation +However, this behavior is officially considered an implementation detail. Other projects which explicitly require ``setuptools`` must still provide an appropriate dependency declaration, rather than assuming ``setuptools`` will always be installed alongside ``pip``. @@ -500,10 +504,10 @@ above. Adding the scripts directory to the system PATH would mean that ``pip`` works reliably in the "only one Python installation on the system PATH" -case, with ``py -m pip`` needed only to select a non-default version in -the parallel installation case (and outside a virtual environment). This -change should also make the ``pyvenv`` command substantially easier to -invoke on Windows, along with all scripts installed by ``pip``, +case, with ``py -m pip``, ``pipX``, or ``pipX.Y`` needed only to select a +non-default version in the parallel installation case (and outside a virtual +environment). This change should also make the ``pyvenv`` command substantially +easier to invoke on Windows, along with all scripts installed by ``pip``, ``easy_install`` and similar tools. While the script invocations on recent versions of Python will run through @@ -531,8 +535,8 @@ downstream distributors: * Do not remove the bundled copy of pip. - * This is required for offline installation of pip into a virtual - environment by the ``venv`` module. + * This is required for installation of pip into a virtual environment by the + ``venv`` module. * This is similar to the existing ``virtualenv`` package for which many downstream distributors have already made exception to the common "debundling" policy. @@ -629,7 +633,7 @@ explicitly invoking ``pip`` following installation). As a result, the PEP was simplified to the current design, where the bootstrapping *always* uses the private copy of ``pip``. Contacting PyPI -is now always an explicit seperate step, with direct access to the full +is now always an explicit separate step, with direct access to the full pip interface. @@ -656,10 +660,10 @@ Including pip directly in the standard library Similar to this PEP is the proposal of just including pip in the standard library. This would ensure that Python always includes pip and fixes all of the end user facing problems with not having pip present by default. This has been -rejected because we've learned through the inclusion and history of -``distutils`` in the standard library that losing the ability to update the +rejected because we've learned, through the inclusion and history of +``distutils`` in the standard library, that losing the ability to update the packaging tools independently can leave the tooling in a state of constant -limbo. Making it unable to ever reasonably evolve in a timeframe that actually +limbo. Making it unable to ever reasonably evolve in a time frame that actually affects users as any new features will not be available to the general population for *years*. @@ -693,8 +697,8 @@ Defaulting to --user installation --------------------------------- Some consideration was given to bootstrapping pip into the per-user -site-packages directory by default. However, this behaviour would be -surprising (as it differs from the default behaviour of pip itself) +site-packages directory by default. However, this behavior would be +surprising (as it differs from the default behavior of pip itself) and is also not currently considered reliable (there are some edge cases which are not handled correctly when pip is installed into the user site-packages directory rather than the system site-packages).