python -m pip install [options] <requirement specifier> [package-index-options] ... python -m pip install [options] -r <requirements file> [package-index-options] ... python -m pip install [options] [-e] <vcs project url> ... python -m pip install [options] [-e] <local project path> ... python -m pip install [options] <archive url/path> ...
py -m pip install [options] <requirement specifier> [package-index-options] ... py -m pip install [options] -r <requirements file> [package-index-options] ... py -m pip install [options] [-e] <vcs project url> ... py -m pip install [options] [-e] <local project path> ... py -m pip install [options] <archive url/path> ...
Install packages from:
PyPI (and other indexes) using requirement specifiers.
VCS project urls.
Local project directories.
Local or remote source archives.
pip also supports installing from “requirements files”, which provide an easy way to specify a whole environment to be installed.
pip install has several stages:
Identify the base requirements. The user supplied arguments are processed here.
Resolve dependencies. What will be installed is determined here.
Build wheels. All the dependencies that can be are built into wheels.
Install the packages (and uninstall anything being upgraded/replaced).
pip install prefers to leave the installed version as-is
--upgrade is specified.
When looking at the items to be installed, pip checks what type of item each is, in the following order:
Project or archive URL.
Local directory (which must contain a
setup.py, or pip will report an error).
Local file (a sdist or wheel format archive, following the naming conventions for those formats).
A requirement, as specified in PEP 440.
Each item identified is added to the set of requirements to be satisfied by the install.
Working Out the Name and Version¶
For each candidate item, pip needs to know the project name and version. For
wheels (identified by the
.whl file extension) this can be obtained from
the filename, as per the Wheel spec. For local directories, or explicitly
specified sdist files, the
setup.py egg_info command is used to determine
the project metadata. For sdists located via an index, the filename is parsed
for the name and project version (this is in theory slightly less reliable
than using the
egg_info command, but avoids downloading and processing
unnecessary numbers of files).
Any URL may use the
#egg=name syntax (see VCS Support) to
explicitly state the project name.
Once pip has the set of requirements to satisfy, it chooses which version of each requirement to install using the simple rule that the latest version that satisfies the given constraints will be installed (but see here for an exception regarding pre-release versions). Where more than one source of the chosen version is available, it is assumed that any source is acceptable (as otherwise the versions would differ).
This section is only about installation order of runtime dependencies, and does not apply to build dependencies (those are specified using PEP 518).
As of v6.1.0, pip installs dependencies before their dependents, i.e. in “topological order.” This is the only commitment pip currently makes related to order. While it may be coincidentally true that pip will install things in the order of the install arguments or in the order of the items in a requirements file, this is not a promise.
In the event of a dependency cycle (aka “circular dependency”), the current implementation (which might possibly change later) has it such that the first encountered member of the cycle is installed last.
For instance, if quux depends on foo which depends on bar which depends on baz, which depends on foo:
$ python -m pip install quux ... Installing collected packages baz, bar, foo, quux $ python -m pip install bar ... Installing collected packages foo, baz, bar
C:\> py -m pip install quux ... Installing collected packages baz, bar, foo, quux C:\> py -m pip install bar ... Installing collected packages foo, baz, bar
Prior to v6.1.0, pip made no commitments about install order.
The decision to install topologically is based on the principle that installations should proceed in a way that leaves the environment usable at each step. This has two main practical benefits:
Concurrent use of the environment during the install is more likely to work.
A failed install is less likely to leave a broken environment. Although pip would like to support failure rollbacks eventually, in the mean time, this is an improvement.
Although the new install order is not intended to replace (and does not replace)
the use of
setup_requires to declare build dependencies, it may help certain
projects install from sdist (that might previously fail) that fit the following
They have build dependencies that are also declared as install dependencies using
python setup.py egg_infoworks without their build dependencies being installed.
For whatever reason, they don’t or won’t declare their build dependencies using
Requirements File Format¶
This section has been moved to Requirements File Format.
pip supports installing from a package index using a requirement
specifier. Generally speaking, a requirement
specifier is composed of a project name followed by optional version
specifiers. PEP 508 contains a full specification
of the format of a requirement. Since version 18.1 pip supports the
SomeProject SomeProject == 1.3 SomeProject >=1.2,<2.0 SomeProject[foo, bar] SomeProject~=1.4.2
Since version 6.0, pip also supports specifiers containing environment markers like so:
SomeProject ==5.4 ; python_version < '3.8' SomeProject; sys_platform == 'win32'
Since version 19.1, pip also supports direct references like so:
SomeProject @ file:///somewhere/...
Environment markers are supported in the command line and in requirements files.
Use quotes around specifiers in the shell when using
<, or when
using environment markers. Don’t use quotes in requirement files. 1
Since version 7.0 pip supports controlling the command line options given to
setup.py via requirements files. This disables the use of wheels (cached or
otherwise) for that package, as
setup.py does not exist for wheels.
--install-option options are used to pass
setup.py. For example:
FooProject >= 1.2 --global-option="--no-user-cfg" \ --install-option="--prefix='/usr/local'" \ --install-option="--no-compile"
The above translates roughly into running FooProject’s
python setup.py --no-user-cfg install --prefix='/usr/local' --no-compile
Note that the only way of giving more than one option to
is through multiple
options, as shown in the example above. The value of each option is
passed as a single argument to the
setup.py script. Therefore, a
line such as the following is invalid and would result in an
# Invalid. Please use '--install-option' twice as shown above. FooProject >= 1.2 --install-option="--prefix=/usr/local --no-compile"
If a Requirement specifier includes a pre-release or development version
>=0.0.dev0) then pip will allow pre-release and development versions
for that requirement. This does not include the != flag.
pip install command also supports a --pre flag
that enables installation of pre-releases and development releases.
This is now covered in VCS Support.
pip offers a number of package index options for modifying how packages are found.
pip looks for packages in a number of places: on PyPI (if not disabled via
--no-index), in the local filesystem, and in any additional repositories
--index-url. There is no ordering in
the locations that are searched. Rather they are all checked, and the “best”
match for the requirements (in terms of version number - see PEP 440 for
details) is selected.
See the pip install Examples.
SSL Certificate Verification¶
Starting with v1.3, pip provides SSL certificate verification over HTTP, to
prevent man-in-the-middle attacks against PyPI downloads. This does not use
the system certificate store but instead uses a bundled CA certificate
store. The default bundled CA certificate store certificate store may be
overridden by using
--cert option or by using
CURL_CA_BUNDLE environment variables.
This is now covered in Caching.
This is now covered in Caching.
Since version 8.0, pip can check downloaded package archives against local hashes to protect against remote tampering. To verify a package against one or more hashes, add them to the end of the line:
FooProject == 1.2 --hash=sha256:2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 \ --hash=sha256:486ea46224d1bb4fb680f34f7c9ad96a8f24ec88be73ea8e5a6c65260e9cb8a7
(The ability to use multiple hashes is important when a package has both binary and source distributions or when it offers binary distributions for a variety of platforms.)
The recommended hash algorithm at the moment is sha256, but stronger ones are
allowed, including all those supported by
hashlib. However, weaker ones
such as md5, sha1, and sha224 are excluded to avoid giving a false sense of
Hash verification is an all-or-nothing proposition. Specifying a
against any requirement not only checks that hash but also activates a global
hash-checking mode, which imposes several other security restrictions:
Hashes are required for all requirements. This is because a partially-hashed requirements file is of little use and thus likely an error: a malicious actor could slip bad code into the installation via one of the unhashed requirements. Note that hashes embedded in URL-style requirements via the
#md5=...syntax suffice to satisfy this rule (regardless of hash strength, for legacy reasons), though you should use a stronger hash like sha256 whenever possible.
Hashes are required for all dependencies. An error results if there is a dependency that is not spelled out and hashed in the requirements file.
Requirements that take the form of project names (rather than URLs or local filesystem paths) must be pinned to a specific version using
==. This prevents a surprising hash mismatch upon the release of a new version that matches the requirement specifier.
--eggis disallowed, because it delegates installation of dependencies to setuptools, giving up pip’s ability to enforce any of the above.
Hash-checking mode can be forced on with the
$ python -m pip install --require-hashes -r requirements.txt ... Hashes are required in --require-hashes mode (implicitly on when a hash is specified for any package). These requirements were missing hashes, leaving them open to tampering. These are the hashes the downloaded archives actually had. You can add lines like these to your requirements files to prevent tampering. pyelasticsearch==1.0 --hash=sha256:44ddfb1225054d7d6b1d02e9338e7d4809be94edbe9929a2ec0807d38df993fa more-itertools==2.2 --hash=sha256:93e62e05c7ad3da1a233def6731e8285156701e3419a5fe279017c429ec67ce0
C:\> py -m pip install --require-hashes -r requirements.txt ... Hashes are required in --require-hashes mode (implicitly on when a hash is specified for any package). These requirements were missing hashes, leaving them open to tampering. These are the hashes the downloaded archives actually had. You can add lines like these to your requirements files to prevent tampering. pyelasticsearch==1.0 --hash=sha256:44ddfb1225054d7d6b1d02e9338e7d4809be94edbe9929a2ec0807d38df993fa more-itertools==2.2 --hash=sha256:93e62e05c7ad3da1a233def6731e8285156701e3419a5fe279017c429ec67ce0
This can be useful in deploy scripts, to ensure that the author of the requirements file provided hashes. It is also a convenient way to bootstrap your list of hashes, since it shows the hashes of the packages it fetched. It fetches only the preferred archive for each package, so you may still need to add hashes for alternatives archives using pip hash: for instance if there is both a binary and a source distribution.
The wheel cache is disabled in hash-checking mode to prevent spurious hash mismatch errors. These would otherwise occur while installing sdists that had already been automatically built into cached wheels: those wheels would be selected for installation, but their hashes would not match the sdist ones from the requirements file. A further complication is that locally built wheels are nondeterministic: contemporary modification times make their way into the archive, making hashes unpredictable across machines and cache flushes. Compilation of C code adds further nondeterminism, as many compilers include random-seeded values in their output. However, wheels fetched from index servers are the same every time. They land in pip’s HTTP cache, not its wheel cache, and are used normally in hash-checking mode. The only downside of having the wheel cache disabled is thus extra build time for sdists, and this can be solved by making sure pre-built wheels are available from the index server.
Beware of the
setup_requires keyword arg in
(rare) packages that use it will cause those dependencies to be downloaded
by setuptools directly, skipping pip’s hash-checking. If you need to use
such a package, see Controlling
Be careful not to nullify all your security work when you install your
actual project by using setuptools directly: for example, by calling
python setup.py install,
python setup.py develop, or
easy_install. Setuptools will happily go out and download, unchecked,
anything you missed in your requirements file—and it’s easy to miss things
as your project evolves. To be safe, install your project using pip and
python setup.py develop, use…
python -m pip install --no-deps -e .
py -m pip install --no-deps -e .
python setup.py install, use…
python -m pip install --no-deps .
py -m pip install --no-deps .
Hashes from PyPI¶
PyPI provides an MD5 hash in the fragment portion of each package download URL,
#md5=123..., which pip checks as a protection against download
corruption. Other hash algorithms that have guaranteed support from
are also supported here: sha1, sha224, sha384, sha256, and sha512. Since this
hash originates remotely, it is not a useful guard against tampering and thus
does not satisfy the
--require-hashes demand that every package have a
Local project installs¶
pip supports installing local project in both regular mode and editable mode. You can install local projects by specifying the project path to pip:
python -m pip install path/to/SomeProject
py -m pip install path/to/SomeProject
Depending on the build backend used by the project, this may generate
secondary build artifacts in the project directory, such as the
build directories in the case of the setuptools
Pip has a legacy behaviour that copies the entire project directory to a temporary location and installs from there. This approach was the cause of several performance and correctness issues, so it is now disabled by default, and it is planned that pip 22.1 will remove it.
To opt in to the legacy behavior, specify the
--use-deprecated=out-of-tree-build option in pip’s command line.
“Editable” installs are fundamentally “setuptools develop mode” installs.
You can install local projects or VCS projects in “editable” mode:
python -m pip install -e path/to/SomeProject python -m pip install -e git+http://repo/my_project.git#egg=SomeProject
py -m pip install -e path/to/SomeProject py -m pip install -e git+http://repo/my_project.git#egg=SomeProject
(See the VCS Support section above for more information on VCS-related syntax.)
For local projects, the “SomeProject.egg-info” directory is created relative to
the project path. This is one advantage over just using
which creates the “egg-info” directly relative the current working directory.
Build System Interface¶
This is now covered in Build System Interface.
- -r, --requirement <file>¶
Install from the given requirements file. This option can be used multiple times.
- -c, --constraint <file>¶
Constrain versions using the given constraints file. This option can be used multiple times.
Don’t install package dependencies.
Include pre-release and development versions. By default, pip only finds stable versions.
- -e, --editable <path/url>¶
Install a project in editable mode (i.e. setuptools “develop mode”) from a local project path or a VCS url.
- -t, --target <dir>¶
Install packages into <dir>. By default this will not replace existing files/folders in <dir>. Use --upgrade to replace existing packages in <dir> with new versions.
- --platform <platform>¶
Only use wheels compatible with <platform>. Defaults to the platform of the running system. Use this option multiple times to specify multiple platforms supported by the target interpreter.
- --python-version <python_version>¶
The Python interpreter version to use for wheel and “Requires-Python” compatibility checks. Defaults to a version derived from the running interpreter. The version can be specified using up to three dot-separated integers (e.g. “3” for 3.0.0, “3.7” for 3.7.0, or “3.7.3”). A major-minor version can also be given as a string without dots (e.g. “37” for 3.7.0).
- --implementation <implementation>¶
Only use wheels compatible with Python implementation <implementation>, e.g. ‘pp’, ‘jy’, ‘cp’, or ‘ip’. If not specified, then the current interpreter implementation is used. Use ‘py’ to force implementation-agnostic wheels.
- --abi <abi>¶
Only use wheels compatible with Python abi <abi>, e.g. ‘pypy_41’. If not specified, then the current interpreter abi tag is used. Use this option multiple times to specify multiple abis supported by the target interpreter. Generally you will need to specify --implementation, --platform, and --python-version when using this option.
Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%Python on Windows. (See the Python documentation for site.USER_BASE for full details.)
- --root <dir>¶
Install everything relative to this alternate root directory.
- --prefix <dir>¶
Installation prefix where lib, bin and other top-level folders are placed
- --src <dir>¶
Directory to check out editable projects into. The default in a virtualenv is “<venv path>/src”. The default for global installs is “<current dir>/src”.
- -U, --upgrade¶
Upgrade all specified packages to the newest available version. The handling of dependencies depends on the upgrade-strategy used.
- --upgrade-strategy <upgrade_strategy>¶
Determines how dependency upgrading should be handled [default: only-if-needed]. “eager” - dependencies are upgraded regardless of whether the currently installed version satisfies the requirements of the upgraded package(s). “only-if-needed” - are upgraded only when they do not satisfy the requirements of the upgraded package(s).
Reinstall all packages even if they are already up-to-date.
- -I, --ignore-installed¶
Ignore the installed packages, overwriting them. This can break your system if the existing package is of a different version or was installed with a different package manager!
Ignore the Requires-Python information.
Disable isolation when building a modern source distribution. Build dependencies specified by PEP 518 must be already installed if this option is used.
Use PEP 517 for building source distributions (use --no-use-pep517 to force legacy behaviour).
- --install-option <options>¶
Extra arguments to be supplied to the setup.py install command (use like --install-option=”--install-scripts=/usr/local/bin”). Use multiple --install-option options to pass multiple options to setup.py install. If you are using an option with a directory path, be sure to use absolute path.
- --global-option <options>¶
Extra global options to be supplied to the setup.py call before the install or bdist_wheel command.
Compile Python source files to bytecode
Do not compile Python source files to bytecode
Do not warn when installing scripts outside PATH
Do not warn about broken dependencies
- --no-binary <format_control>¶
Do not use binary packages. Can be supplied multiple times, and each time adds to the existing value. Accepts either “:all:” to disable all binary packages, “:none:” to empty the set (notice the colons), or one or more package names with commas between them (no colons). Note that some packages are tricky to compile and may fail to install when this option is used on them.
- --only-binary <format_control>¶
Do not use source packages. Can be supplied multiple times, and each time adds to the existing value. Accepts either “:all:” to disable all source packages, “:none:” to empty the set, or one or more package names with commas between them. Packages without binary distributions will fail to install when this option is used on them.
Prefer older binary packages over newer source packages.
Require a hash to check each requirement against, for repeatable installs. This option is implied when any package in a requirements file has a --hash option.
- --progress-bar <progress_bar>¶
Specify type of progress to be displayed [off|on|ascii|pretty|emoji] (default: on)
Don’t clean up build directories.
- -i, --index-url <url>¶
Base URL of the Python Package Index (default https://pypi.org/simple). This should point to a repository compliant with PEP 503 (the simple repository API) or a local directory laid out in the same format.
- --extra-index-url <url>¶
Extra URLs of package indexes to use in addition to --index-url. Should follow the same rules as --index-url.
Ignore package index (only looking at --find-links URLs instead).
python -m pip install SomePackage # latest version python -m pip install SomePackage==1.0.4 # specific version python -m pip install 'SomePackage>=1.0.4' # minimum version
py -m pip install SomePackage # latest version py -m pip install SomePackage==1.0.4 # specific version py -m pip install 'SomePackage>=1.0.4' # minimum version
Install a list of requirements specified in a file. See the Requirements files.
python -m pip install -r requirements.txt
py -m pip install -r requirements.txt
Upgrade an already installed
SomePackageto the latest from PyPI.
python -m pip install --upgrade SomePackage
py -m pip install --upgrade SomePackage
This will guarantee an update to
SomePackageas it is a direct requirement, and possibly upgrade dependencies if their installed versions do not meet the minimum requirements of
SomePackage. Any non-requisite updates of its dependencies (indirect requirements) will be affected by the
Install a local project in “editable” mode. See the section on Editable Installs.
python -m pip install -e . # project in current directory python -m pip install -e path/to/project # project in another directory
py -m pip install -e . # project in current directory py -m pip install -e path/to/project # project in another directory
Install a project from VCS
python -m pip install SomeProject@git+https://email@example.com
py -m pip install SomeProject@git+https://firstname.lastname@example.org
python -m pip install -e git+https://git.repo/some_pkg.git#egg=SomePackage # from git python -m pip install -e hg+https://hg.repo/some_pkg.git#egg=SomePackage # from mercurial python -m pip install -e svn+svn://svn.repo/some_pkg/trunk/#egg=SomePackage # from svn python -m pip install -e git+https://git.repo/some_pkg.git@feature#egg=SomePackage # from 'feature' branch python -m pip install -e "git+https://git.repo/some_repo.git#egg=subdir&subdirectory=subdir_path" # install a python package from a repo subdirectory
py -m pip install -e git+https://git.repo/some_pkg.git#egg=SomePackage # from git py -m pip install -e hg+https://hg.repo/some_pkg.git#egg=SomePackage # from mercurial py -m pip install -e svn+svn://svn.repo/some_pkg/trunk/#egg=SomePackage # from svn py -m pip install -e git+https://git.repo/some_pkg.git@feature#egg=SomePackage # from 'feature' branch py -m pip install -e "git+https://git.repo/some_repo.git#egg=subdir&subdirectory=subdir_path" # install a python package from a repo subdirectory
Install a package with setuptools extras.
python -m pip install SomePackage[PDF] python -m pip install "SomePackage[PDF] @ git+https://git.repo/SomePackage@main#subdirectory=subdir_path" python -m pip install .[PDF] # project in current directory python -m pip install SomePackage[PDF]==3.0 python -m pip install SomePackage[PDF,EPUB] # multiple extras
py -m pip install SomePackage[PDF] py -m pip install "SomePackage[PDF] @ git+https://git.repo/SomePackage@main#subdirectory=subdir_path" py -m pip install .[PDF] # project in current directory py -m pip install SomePackage[PDF]==3.0 py -m pip install SomePackage[PDF,EPUB] # multiple extras
Install a particular source archive file.
python -m pip install ./downloads/SomePackage-1.0.4.tar.gz python -m pip install http://my.package.repo/SomePackage-1.0.4.zip
py -m pip install ./downloads/SomePackage-1.0.4.tar.gz py -m pip install http://my.package.repo/SomePackage-1.0.4.zip
Install a particular source archive file following PEP 440 direct references.
python -m pip install SomeProject@http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl python -m pip install "SomeProject @ http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl" python -m pip install SomeProject@http://my.package.repo/1.2.3.tar.gz
py -m pip install SomeProject@http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl py -m pip install "SomeProject @ http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl" py -m pip install SomeProject@http://my.package.repo/1.2.3.tar.gz
Install from alternative package repositories.
Install from a different index, and not PyPI
python -m pip install --index-url http://my.package.repo/simple/ SomePackage
py -m pip install --index-url http://my.package.repo/simple/ SomePackage
Install from a local flat directory containing archives (and don’t scan indexes):
python -m pip install --no-index --find-links=file:///local/dir/ SomePackage python -m pip install --no-index --find-links=/local/dir/ SomePackage python -m pip install --no-index --find-links=relative/dir/ SomePackage
py -m pip install --no-index --find-links=file:///local/dir/ SomePackage py -m pip install --no-index --find-links=/local/dir/ SomePackage py -m pip install --no-index --find-links=relative/dir/ SomePackage
Search an additional index during install, in addition to PyPI
Using this option to search for packages which are not in the main repository (such as private packages) is unsafe, per a security vulnerability called dependency confusion: an attacker can claim the package on the public repository in a way that will ensure it gets chosen over the private package.
python -m pip install --extra-index-url http://my.package.repo/simple SomePackage
py -m pip install --extra-index-url http://my.package.repo/simple SomePackage
Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions.
python -m pip install --pre SomePackage
py -m pip install --pre SomePackage
Install packages from source.
Do not use any binary packages
python -m pip install SomePackage1 SomePackage2 --no-binary :all:
py -m pip install SomePackage1 SomePackage2 --no-binary :all:
SomePackage1to be installed from source:
python -m pip install SomePackage1 SomePackage2 --no-binary SomePackage1
py -m pip install SomePackage1 SomePackage2 --no-binary SomePackage1
This is true with the exception that pip v7.0 and v7.0.1 required quotes around specifiers containing environment markers in requirement files.