pip

Usage

Unix/macOS

python -m pip <command> [options]

Windows

py -m pip <command> [options]

Description

Logging

Console logging

pip offers -v, —verbose and -q, —quiet to control the console log level. By default, some messages (error and warnings) are colored in the terminal. If you want to suppress the colored output use --no-color.

File logging

pip offers the --log option for specifying a file where a maximum verbosity log will be kept. This option is empty by default. This log appends to previous logging.

Like all pip options, --log can also be set as an environment variable, or placed into the pip config file. See the Configuration section.

--exists-action option

This option specifies default behavior when path already exists. Possible cases: downloading files or checking out repositories for installation, creating archives. If --exists-action is not defined, pip will prompt when decision is needed.

(s)witch

Only relevant to VCS checkout. Attempt to switch the checkout to the appropriate URL and/or revision.

(i)gnore

Abort current operation (e.g. don’t copy file, don’t create archive, don’t modify a checkout).

(w)ipe

Delete the file or VCS checkout before trying to create, download, or checkout a new one.

(b)ackup

Rename the file or checkout to {name}{'.bak' * n}, where n is some number of .bak extensions, such that the file didn’t exist at some point. So the most recent backup will be the one with the largest number after .bak.

(a)abort

Abort pip and return non-zero exit status.

Build System Interface

pip builds packages by invoking the build system. By default, builds will use setuptools, but if a project specifies a different build system using a pyproject.toml file, as per PEP 517, pip will use that instead. As well as package building, the build system is also invoked to install packages direct from source. This is handled by invoking the build system to build a wheel, and then installing from that wheel. The built wheel is cached locally by pip to avoid repeated identical builds.

The current interface to the build system is via the setup.py command line script - all build actions are defined in terms of the specific setup.py command line that will be run to invoke the required action.

Setuptools Injection

When PEP 517 is not used, the supported build system is setuptools. However, not all packages use setuptools in their build scripts. To support projects that use “pure distutils”, pip injects setuptools into sys.modules before invoking setup.py. The injection should be transparent to distutils-based projects, but 3rd party build tools wishing to provide a setup.py emulating the commands pip requires may need to be aware that it takes place.

Projects using PEP 517 must explicitly use setuptools - pip does not do the above injection process in this case.

Build System Output

Any output produced by the build system will be read by pip (for display to the user if requested). In order to correctly read the build system output, pip requires that the output is written in a well-defined encoding, specifically the encoding the user has configured for text output (which can be obtained in Python using locale.getpreferredencoding). If the configured encoding is ASCII, pip assumes UTF-8 (to account for the behaviour of some Unix systems).

Build systems should ensure that any tools they invoke (compilers, etc) produce output in the correct encoding. In practice - and in particular on Windows, where tools are inconsistent in their use of the “OEM” and “ANSI” codepages - this may not always be possible. pip will therefore attempt to recover cleanly if presented with incorrectly encoded build tool output, by translating unexpected byte sequences to Python-style hexadecimal escape sequences ("\x80\xff", etc). However, it is still possible for output to be displayed using an incorrect encoding (mojibake).

Under PEP 517, handling of build tool output is the backend’s responsibility, and pip simply displays the output produced by the backend. (Backends, however, will likely still have to address the issues described above).

PEP 517 and 518 Support

As of version 10.0, pip supports projects declaring dependencies that are required at install time using a pyproject.toml file, in the form described in PEP 518. When building a project, pip will install the required dependencies locally, and make them available to the build process. Furthermore, from version 19.0 onwards, pip supports projects specifying the build backend they use in pyproject.toml, in the form described in PEP 517.

When making build requirements available, pip does so in an isolated environment. That is, pip does not install those requirements into the user’s site-packages, but rather installs them in a temporary directory which it adds to the user’s sys.path for the duration of the build. This ensures that build requirements are handled independently of the user’s runtime environment. For example, a project that needs a recent version of setuptools to build can still be installed, even if the user has an older version installed (and without silently replacing that version).

In certain cases, projects (or redistributors) may have workflows that explicitly manage the build environment. For such workflows, build isolation can be problematic. If this is the case, pip provides a --no-build-isolation flag to disable build isolation. Users supplying this flag are responsible for ensuring the build environment is managed appropriately (including ensuring that all required build dependencies are installed).

By default, pip will continue to use the legacy (direct setup.py execution based) build processing for projects that do not have a pyproject.toml file. Projects with a pyproject.toml file will use a PEP 517 backend. Projects with a pyproject.toml file, but which don’t have a build-system section, will be assumed to have the following backend settings:

[build-system]
requires = ["setuptools>=40.8.0", "wheel"]
build-backend = "setuptools.build_meta:__legacy__"

Note

setuptools 40.8.0 is the first version of setuptools that offers a PEP 517 backend that closely mimics directly executing setup.py.

If a project has [build-system], but no build-backend, pip will also use setuptools.build_meta:__legacy__, but will expect the project requirements to include setuptools and wheel (and will report an error if the installed version of setuptools is not recent enough).

If a user wants to explicitly request PEP 517 handling even though a project doesn’t have a pyproject.toml file, this can be done using the --use-pep517 command line option. Similarly, to request legacy processing even though pyproject.toml is present, the --no-use-pep517 option is available (although obviously it is an error to choose --no-use-pep517 if the project has no setup.py, or explicitly requests a build backend). As with other command line flags, pip recognises the PIP_USE_PEP517 environment veriable and a use-pep517 config file option (set to true or false) to set this option globally. Note that overriding pip’s choice of whether to use PEP 517 processing in this way does not affect whether pip will use an isolated build environment (which is controlled via --no-build-isolation as noted above).

Except in the case noted above (projects with no PEP 518 [build-system] section in pyproject.toml), pip will never implicitly install a build system. Projects must ensure that the correct build system is listed in their requires list (this applies even if pip assumes that the setuptools backend is being used, as noted above).

Historical Limitations:

• pip<18.0: only supports installing build requirements from wheels, and does not support the use of environment markers and extras (only version specifiers are respected).

• pip<18.1: build dependencies using .pth files are not properly supported; as a result namespace packages do not work under Python 3.2 and earlier.

Future Developments

PEP 426 notes that the intention is to add hooks to project metadata in version 2.1 of the metadata spec, to explicitly define how to build a project from its source. Once this version of the metadata spec is final, pip will migrate to using that interface. At that point, the setup.py interface documented here will be retained solely for legacy purposes, until projects have migrated.

Specifically, applications should not expect to rely on there being any form of backward compatibility guarantees around the setup.py interface.

Build Options

The --global-option and --build-option arguments to the pip install and pip wheel inject additional arguments into the setup.py command (--build-option is only available in pip wheel). These arguments are included in the command as follows:

Unix/macOS

python setup.py <global_options> BUILD COMMAND <build_options>

Windows

py setup.py <global_options> BUILD COMMAND <build_options>

The options are passed unmodified, and presently offer direct access to the distutils command line. Use of --global-option and --build-option should be considered as build system dependent, and may not be supported in the current form if support for alternative build systems is added to pip.

General Options

-h``, --help

Show help.

--isolated

Run pip in an isolated mode, ignoring environment variables and user configuration.

-v``, --verbose

Give more output. Option is additive, and can be used up to 3 times.

-V``, --version

Show version and exit.

-q``, --quiet

Give less output. Option is additive, and can be used up to 3 times (corresponding to WARNING, ERROR, and CRITICAL logging levels).

--log <path>

Path to a verbose appending log.

--no-input

Disable prompting for input.

--proxy <proxy>

Specify a proxy in the form [user:passwd@]proxy.server:port.

--retries <retries>

Maximum number of retries each connection should attempt (default 5 times).

--timeout <sec>

Set the socket timeout (default 15 seconds).

--exists-action <action>

Default action when a path already exists: (s)witch, (i)gnore, (w)ipe, (b)ackup, (a)bort.

--trusted-host <hostname>

Mark this host or host:port pair as trusted, even though it does not have valid or any HTTPS.

--cert <path>

Path to alternate CA bundle.

--client-cert <path>

Path to SSL client certificate, a single file containing the private key and the certificate in PEM format.

--cache-dir <dir>

Store the cache data in <dir>.

--no-cache-dir

Disable the cache.

--disable-pip-version-check

Don’t periodically check PyPI to determine whether a new version of pip is available for download. Implied with —no-index.

--no-color

Suppress colored output.

--no-python-version-warning

Silence deprecation warnings for upcoming unsupported Pythons.

--use-feature <feature>

Enable new functionality, that may be backward incompatible.

--use-deprecated <feature>

Enable deprecated functionality, that will be removed in the future.

Important

Did this article help?

We are currently doing research to improve pip’s documentation and would love your feedback. Please email us &body=%0A%20%20%20%200.%20Document:%20reference/pip.%20Page%20URL:%20https:/%20%0A%0A%20%20%20%201.%20What%20problem%20were%20you%20trying%20to%20solve%20when%20you%20came%20to%20this%20page?%20%0A%0A%20%20%20%202.%20What%20content%20was%20useful?%20%0A%0A%20%20%20%203.%20What%20content%20was%20not%20useful?) and let us know:

1. What problem were you trying to solve when you came to this page?

2. What content was useful?

3. What content was not useful?