pip install

Usage

Unix/macOS

  1. python -m pip install [options] <requirement specifier> [package-index-options] ...
  2. python -m pip install [options] -r <requirements file> [package-index-options] ...
  3. python -m pip install [options] [-e] <vcs project url> ...
  4. python -m pip install [options] [-e] <local project path> ...
  5. python -m pip install [options] <archive url/path> ...

Windows

  1. py -m pip install [options] <requirement specifier> [package-index-options] ...
  2. py -m pip install [options] -r <requirements file> [package-index-options] ...
  3. py -m pip install [options] [-e] <vcs project url> ...
  4. py -m pip install [options] [-e] <local project path> ...
  5. py -m pip install [options] <archive url/path> ...

Description

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.

Overview

pip install has several stages:

  1. Identify the base requirements. The user supplied arguments are processed here.

  2. Resolve dependencies. What will be installed is determined here.

  3. Build wheels. All the dependencies that can be are built into wheels.

  4. Install the packages (and uninstall anything being upgraded/replaced).

Note that pip install prefers to leave the installed version as-is unless --upgrade is specified.

Argument Handling

When looking at the items to be installed, pip checks what type of item each is, in the following order:

  1. Project or archive URL.

  2. Local directory (which must contain a setup.py, or pip will report an error).

  3. Local file (a sdist or wheel format archive, following the naming conventions for those formats).

  4. 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.

Satisfying Requirements

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).

Installation Order

Note

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:

Unix/macOS

  1. $ python -m pip install quux
  2. ...
  3. Installing collected packages baz, bar, foo, quux
  5. $ python -m pip install bar
  6. ...
  7. Installing collected packages foo, baz, bar

Windows

  1. C:\> py -m pip install quux
  2. ...
  3. Installing collected packages baz, bar, foo, quux
  5. C:\> py -m pip install bar
  6. ...
  7. 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:

  1. Concurrent use of the environment during the install is more likely to work.

  2. 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 profile:

  1. They have build dependencies that are also declared as install dependencies using install_requires.

  2. python setup.py egg_info works without their build dependencies being installed.

  3. For whatever reason, they don’t or won’t declare their build dependencies using setup_requires.

Requirements File Format

Each line of the requirements file indicates something to be installed, and like arguments to pip install, the following forms are supported:

  1. [[--option]...]
  2. <requirement specifier> [; markers] [[--option]...]
  3. <archive url/path>
  4. [-e] <local project path>
  5. [-e] <vcs project url>

For details on requirement specifiers, see Requirement Specifiers.

See the pip install Examples for examples of all these forms.

A line that begins with # is treated as a comment and ignored. Whitespace followed by a # causes the # and the remainder of the line to be treated as a comment.

A line ending in an unescaped \ is treated as a line continuation and the newline following it is effectively ignored.

Comments are stripped after line continuations are processed.

To interpret the requirements file in UTF-8 format add a comment # -*- coding: utf-8 -*- to the first or second line of the file.

The following options are supported:

Please note that the above options are global options, and should be specified on their individual lines. The options which can be applied to individual requirements are --install-option, --global-option and --hash.

For example, to specify --pre, --no-index and two --find-links locations:

  1. --pre
  2. --no-index
  3. --find-links /my/local/archives
  4. --find-links http://some.archives.com/archives

If you wish, you can refer to other requirements files, like this:

  1. -r more_requirements.txt

You can also refer to constraints files, like this:

  1. -c some_constraints.txt

Using Environment Variables

Since version 10, pip supports the use of environment variables inside the requirements file. You can now store sensitive data (tokens, keys, etc.) in environment variables and only specify the variable name for your requirements, letting pip lookup the value at runtime. This approach aligns with the commonly used 12-factor configuration pattern.

You have to use the POSIX format for variable names including brackets around the uppercase name as shown in this example: ${API_TOKEN}. pip will attempt to find the corresponding environment variable defined on the host system at runtime.

Note

There is no support for other variable expansion syntaxes such as $VARIABLE and %VARIABLE%.

Example Requirements File

Use pip install -r example-requirements.txt to install:

  1. #
  2. ####### example-requirements.txt #######
  3. #
  4. ###### Requirements without Version Specifiers ######
  5. nose
  6. nose-cov
  7. beautifulsoup4
  8. #
  9. ###### Requirements with Version Specifiers ######
  10. #   See https://www.python.org/dev/peps/pep-0440/#version-specifiers
  11. docopt == 0.6.1             # Version Matching. Must be version 0.6.1
  12. keyring >= 4.1.1            # Minimum version 4.1.1
  13. coverage != 3.5             # Version Exclusion. Anything except version 3.5
  14. Mopidy-Dirble ~= 1.1        # Compatible release. Same as >= 1.1, == 1.*
  15. #
  16. ###### Refer to other requirements files ######
  17. -r other-requirements.txt
  18. #
  19. #
  20. ###### A particular file ######
  21. ./downloads/numpy-1.9.2-cp34-none-win32.whl
  22. http://wxpython.org/Phoenix/snapshot-builds/wxPython_Phoenix-3.0.3.dev1820+49a8884-cp34-none-win_amd64.whl
  23. #
  24. ###### Additional Requirements without Version Specifiers ######
  25. #   Same as 1st section, just here to show that you can put things in any order.
  26. rejected
  27. green
  28. #

Requirement Specifiers

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 url_req-form specification.

Some examples:

  1. SomeProject
  2. SomeProject == 1.3
  3. SomeProject >=1.2,<2.0
  4. SomeProject[foo, bar]
  5. SomeProject~=1.4.2

Since version 6.0, pip also supports specifiers containing environment markers like so:

  1. SomeProject ==5.4 ; python_version < '2.7'
  2. SomeProject; sys_platform == 'win32'

Since version 19.1, pip also supports direct references like so:

  1. SomeProject @ file:///somewhere/...

Environment markers are supported in the command line and in requirements files.

Note

Use quotes around specifiers in the shell when using >, <, or when using environment markers. Don’t use quotes in requirement files. 1

Per-requirement Overrides

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.

The --global-option and --install-option options are used to pass options to setup.py. For example:

  1. FooProject >= 1.2 --global-option="--no-user-cfg" \
  2.                   --install-option="--prefix='/usr/local'" \
  3.                   --install-option="--no-compile"

The above translates roughly into running FooProject’s setup.py script as:

  1. python setup.py --no-user-cfg install --prefix='/usr/local' --no-compile

Note that the only way of giving more than one option to setup.py is through multiple --global-option and --install-option 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 installation error.

  1. # Invalid. Please use '--install-option' twice as shown above.
  2. FooProject >= 1.2 --install-option="--prefix=/usr/local --no-compile"

Pre-release Versions

Starting with v1.4, pip will only install stable versions as specified by pre-releases by default. If a version cannot be parsed as a compliant PEP 440 version then it is assumed to be a pre-release.

If a Requirement specifier includes a pre-release or development version (e.g. >=0.0.dev0) then pip will allow pre-release and development versions for that requirement. This does not include the != flag.

The pip install command also supports a --pre flag that enables installation of pre-releases and development releases.

VCS Support

pip supports installing from Git, Mercurial, Subversion and Bazaar, and detects the type of VCS using URL prefixes: git+, hg+, svn+, and bzr+.

pip requires a working VCS command on your path: git, hg, svn, or bzr.

VCS projects can be installed in editable mode (using the --editable option) or not.

  • For editable installs, the clone location by default is <venv path>/src/SomeProject in virtual environments, and <cwd>/src/SomeProject for global installs. The --src option can be used to modify this location.

  • For non-editable installs, the project is built locally in a temp dir and then installed normally. Note that if a satisfactory version of the package is already installed, the VCS source will not overwrite it without an --upgrade flag. VCS requirements pin the package version (specified in the setup.py file) of the target commit, not necessarily the commit itself.

  • The pip freeze subcommand will record the VCS requirement specifier (referencing a specific commit) if and only if the install is done using the editable option.

The “project name” component of the URL suffix egg=<project name> is used by pip in its dependency logic to identify the project prior to pip downloading and analyzing the metadata. For projects where setup.py is not in the root of project, the “subdirectory” component is used. The value of the “subdirectory” component should be a path starting from the root of the project to where setup.py is located.

If your repository layout is:

  1. pkg_dir
  2. ├── setup.py  # setup.py for package "pkg"
  3. └── some_module.py
  4. other_dir
  5. └── some_file
  6. some_other_file

Then, to install from this repository, the syntax would be:

Unix/macOS

  1. python -m pip install -e "vcs+protocol://repo_url/#egg=pkg&subdirectory=pkg_dir"

Windows

  1. py -m pip install -e "vcs+protocol://repo_url/#egg=pkg&subdirectory=pkg_dir"

Git

pip currently supports cloning over git, git+http, git+https, git+ssh, git+git and git+file.

Warning

Note that the use of git, git+git, and git+http is discouraged. The former two use the Git Protocol, which lacks authentication, and HTTP is insecure due to lack of TLS based encryption.

Here are the supported forms:

  1. [-e] git+http://git.example.com/MyProject#egg=MyProject
  2. [-e] git+https://git.example.com/MyProject#egg=MyProject
  3. [-e] git+ssh://git.example.com/MyProject#egg=MyProject
  4. [-e] git+file:///home/user/projects/MyProject#egg=MyProject

Passing a branch name, a commit hash, a tag name or a git ref is possible like so:

  1. [-e] git+https://git.example.com/MyProject.git@master#egg=MyProject
  2. [-e] git+https://git.example.com/MyProject.git@v1.0#egg=MyProject
  3. [-e] git+https://git.example.com/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709#egg=MyProject
  4. [-e] git+https://git.example.com/MyProject.git@refs/pull/123/head#egg=MyProject

When passing a commit hash, specifying a full hash is preferable to a partial hash because a full hash allows pip to operate more efficiently (e.g. by making fewer network calls).

Mercurial

The supported schemes are: hg+file, hg+http, hg+https, hg+static-http, and hg+ssh.

Here are the supported forms:

  1. [-e] hg+http://hg.myproject.org/MyProject#egg=MyProject
  2. [-e] hg+https://hg.myproject.org/MyProject#egg=MyProject
  3. [-e] hg+ssh://hg.myproject.org/MyProject#egg=MyProject
  4. [-e] hg+file:///home/user/projects/MyProject#egg=MyProject

You can also specify a revision number, a revision hash, a tag name or a local branch name like so:

  1. [-e] hg+http://hg.example.com/MyProject@da39a3ee5e6b#egg=MyProject
  2. [-e] hg+http://hg.example.com/MyProject@2019#egg=MyProject
  3. [-e] hg+http://hg.example.com/MyProject@v1.0#egg=MyProject
  4. [-e] hg+http://hg.example.com/MyProject@special_feature#egg=MyProject

Subversion

pip supports the URL schemes svn, svn+svn, svn+http, svn+https, svn+ssh.

Here are some of the supported forms:

  1. [-e] svn+https://svn.example.com/MyProject#egg=MyProject
  2. [-e] svn+ssh://svn.example.com/MyProject#egg=MyProject
  3. [-e] svn+ssh://user@svn.example.com/MyProject#egg=MyProject

You can also give specific revisions to an SVN URL, like so:

  1. [-e] svn+svn://svn.example.com/svn/MyProject#egg=MyProject
  2. [-e] svn+http://svn.example.com/svn/MyProject/trunk@2019#egg=MyProject

which will check out revision 2019. @{20080101} would also check out the revision from 2008-01-01. You can only check out specific revisions using -e svn+....

Bazaar

pip supports Bazaar using the bzr+http, bzr+https, bzr+ssh, bzr+sftp, bzr+ftp and bzr+lp schemes.

Here are the supported forms:

  1. [-e] bzr+http://bzr.example.com/MyProject/trunk#egg=MyProject
  2. [-e] bzr+sftp://user@example.com/MyProject/trunk#egg=MyProject
  3. [-e] bzr+ssh://user@example.com/MyProject/trunk#egg=MyProject
  4. [-e] bzr+ftp://user@example.com/MyProject/trunk#egg=MyProject
  5. [-e] bzr+lp:MyProject#egg=MyProject

Tags or revisions can be installed like so:

  1. [-e] bzr+https://bzr.example.com/MyProject/trunk@2019#egg=MyProject
  2. [-e] bzr+http://bzr.example.com/MyProject/trunk@v1.0#egg=MyProject

Using Environment Variables

Since version 10, pip also makes it possible to use environment variables which makes it possible to reference private repositories without having to store access tokens in the requirements file. For example, a private git repository allowing Basic Auth for authentication can be refenced like this:

  1. [-e] git+http://${AUTH_USER}:${AUTH_PASSWORD}@git.example.com/MyProject#egg=MyProject
  2. [-e] git+https://${AUTH_USER}:${AUTH_PASSWORD}@git.example.com/MyProject#egg=MyProject

Note

Only ${VARIABLE} is supported, other formats like $VARIABLE or %VARIABLE% won’t work.

Finding Packages

pip searches for packages on PyPI using the HTTP simple interface, which is documented here and there.

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 specified via --find-links or --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 https, to prevent man-in-the-middle attacks against PyPI downloads.

Caching

Starting with v6.0, pip provides an on-by-default cache which functions similarly to that of a web browser. While the cache is on by default and is designed do the right thing by default you can disable the cache and always access PyPI by utilizing the --no-cache-dir option.

When making any HTTP request pip will first check its local cache to determine if it has a suitable response stored for that request which has not expired. If it does then it simply returns that response and doesn’t make the request.

If it has a response stored, but it has expired, then it will attempt to make a conditional request to refresh the cache which will either return an empty response telling pip to simply use the cached item (and refresh the expiration timer) or it will return a whole new response which pip can then store in the cache.

While this cache attempts to minimize network activity, it does not prevent network access altogether. If you want a local install solution that circumvents accessing PyPI, see Installing from local packages.

The default location for the cache directory depends on the operating system:

Unix

~/.cache/pip and it respects the XDG_CACHE_HOME directory.

macOS

~/Library/Caches/pip.

Windows

<CSIDL_LOCAL_APPDATA>\pip\Cache

Run pip cache dir to show the cache directory and see pip cache to inspect and manage pip’s cache.

Wheel Cache

pip will read from the subdirectory wheels within the pip cache directory and use any packages found there. This is disabled via the same --no-cache-dir option that disables the HTTP cache. The internal structure of that is not part of the pip API. As of 7.0, pip makes a subdirectory for each sdist that wheels are built from and places the resulting wheels inside.

As of version 20.0, pip also caches wheels when building from an immutable Git reference (i.e. a commit hash).

pip attempts to choose the best wheels from those built in preference to building a new wheel. Note that this means when a package has both optional C extensions and builds py tagged wheels when the C extension can’t be built that pip will not attempt to build a better wheel for Pythons that would have supported it, once any generic wheel is built. To correct this, make sure that the wheels are built with Python specific tags - e.g. pp on PyPy.

When no wheels are found for an sdist, pip will attempt to build a wheel automatically and insert it into the wheel cache.

Hash-Checking Mode

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:

  1. FooProject == 1.2 --hash=sha256:2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 \
  2.                   --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 security.

Hash verification is an all-or-nothing proposition. Specifying a --hash 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.

  • --egg is 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 --require-hashes command-line option:

Unix/macOS

  1. $ python -m pip install --require-hashes -r requirements.txt
  2. ...
  3. Hashes are required in --require-hashes mode (implicitly on when a hash is
  4. specified for any package). These requirements were missing hashes,
  5. leaving them open to tampering. These are the hashes the downloaded
  6. archives actually had. You can add lines like these to your requirements
  7. files to prevent tampering.
  8.    pyelasticsearch==1.0 --hash=sha256:44ddfb1225054d7d6b1d02e9338e7d4809be94edbe9929a2ec0807d38df993fa
  9.    more-itertools==2.2 --hash=sha256:93e62e05c7ad3da1a233def6731e8285156701e3419a5fe279017c429ec67ce0

Windows

  1. C:\> py -m pip install --require-hashes -r requirements.txt
  2. ...
  3. Hashes are required in --require-hashes mode (implicitly on when a hash is
  4. specified for any package). These requirements were missing hashes,
  5. leaving them open to tampering. These are the hashes the downloaded
  6. archives actually had. You can add lines like these to your requirements
  7. files to prevent tampering.
  8.    pyelasticsearch==1.0 --hash=sha256:44ddfb1225054d7d6b1d02e9338e7d4809be94edbe9929a2ec0807d38df993fa
  9.    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.

Hash-checking mode also works with pip download and pip wheel. A comparison of hash-checking mode with other repeatability strategies is available in the User Guide.

Warning

Beware of the setup_requires keyword arg in setup.py. The (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 setup_requires.

Warning

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 --no-deps.

Instead of python setup.py develop, use…

Unix/macOS

  1. python -m pip install --no-deps -e .

Windows

  1. py -m pip install --no-deps -e .

Instead of python setup.py install, use…

Unix/macOS

  1. python -m pip install --no-deps .

Windows

  1. py -m pip install --no-deps .

Hashes from PyPI

PyPI provides an MD5 hash in the fragment portion of each package download URL, like #md5=123..., which pip checks as a protection against download corruption. Other hash algorithms that have guaranteed support from hashlib 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 hash.

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:

Unix/macOS

  1. python -m pip install path/to/SomeProject

Windows

  1. py -m pip install path/to/SomeProject

During regular installation, pip will copy the entire project directory to a temporary location and install from there. The exception is that pip will exclude .tox and .nox directories present in the top level of the project from being copied.

“Editable” Installs

“Editable” installs are fundamentally “setuptools develop mode” installs.

You can install local projects or VCS projects in “editable” mode:

Unix/macOS

  1. python -m pip install -e path/to/SomeProject
  2. python -m pip install -e git+http://repo/my_project.git#egg=SomeProject

Windows

  1. py -m pip install -e path/to/SomeProject
  2. 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 setup.py develop, which creates the “egg-info” directly relative the current working directory.

Controlling setup_requires

Setuptools offers the setup_requires setup() keyword for specifying dependencies that need to be present in order for the setup.py script to run. Internally, Setuptools uses easy_install to fulfill these dependencies.

pip has no way to control how these dependencies are located. None of the package index options have an effect.

The solution is to configure a “system” or “personal” Distutils configuration file to manage the fulfillment.

For example, to have the dependency located at an alternate index, add this:

  1. [easy_install]
  2. index_url = https://my.index-mirror.com

To have the dependency located from a local directory and not crawl PyPI, add this:

  1. [easy_install]
  2. allow_hosts = ''
  3. find_links = file:///path/to/local/archives/

Build System Interface

In order for pip to install a package from source, setup.py must implement the following commands:

  1. setup.py egg_info [--egg-base XXX]
  2. setup.py install --record XXX [--single-version-externally-managed] [--root XXX] [--compile|--no-compile] [--install-headers XXX]

The egg_info command should create egg metadata for the package, as described in the setuptools documentation at https://setuptools.readthedocs.io/en/latest/setuptools.html#egg-info-create-egg-metadata-and-set-build-tags

The install command should implement the complete process of installing the package to the target directory XXX.

To install a package in “editable” mode (pip install -e), setup.py must implement the following command:

  1. setup.py develop --no-deps

This should implement the complete process of installing the package in “editable” mode.

All packages will be attempted to built into wheels:

  1. setup.py bdist_wheel -d XXX

One further setup.py command is invoked by pip install:

  1. setup.py clean

This command is invoked to clean up temporary commands from the build. (TODO: Investigate in more detail when this command is required).

No other build system commands are invoked by the pip install command.

Installing a package from a wheel does not invoke the build system at all.

Options

-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.

--no-deps

Don’t install package dependencies.

--pre

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.

--user

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).

--force-reinstall

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-requires-python

Ignore the Requires-Python information.

--no-build-isolation

Disable isolation when building a modern source distribution. Build dependencies specified by PEP 518 must be already installed if this option is used.

--use-pep517

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 command.

--compile

Compile Python source files to bytecode

--no-compile

Do not compile Python source files to bytecode

--no-warn-script-location

Do not warn when installing scripts outside PATH

--no-warn-conflicts

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-binary

Prefer older binary packages over newer source packages.

--require-hashes

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)

--no-clean

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.

--no-index

Ignore package index (only looking at —find-links URLs instead).

-f``, --find-links <url>

If a URL or path to an html file, then parse for links to archives such as sdist (.tar.gz) or wheel (.whl) files. If a local path or file:// URL that’s a directory, then look for archives in the directory listing. Links to VCS project URLs are not supported.

Examples

  1. Install SomePackage and its dependencies from PyPI using Requirement Specifiers

    Unix/macOS

    1. python -m pip install SomePackage            # latest version
    2. python -m pip install SomePackage==1.0.4     # specific version
    3. python -m pip install 'SomePackage>=1.0.4'   # minimum version

    Windows

    1. py -m pip install SomePackage            # latest version
    2. py -m pip install SomePackage==1.0.4     # specific version
    3. py -m pip install 'SomePackage>=1.0.4'   # minimum version

  2. Install a list of requirements specified in a file. See the Requirements files.

    Unix/macOS

    1. python -m pip install -r requirements.txt

    Windows

    1. py -m pip install -r requirements.txt

  3. Upgrade an already installed SomePackage to the latest from PyPI.

    Unix/macOS

    1. python -m pip install --upgrade SomePackage

    Windows

    1. py -m pip install --upgrade SomePackage

  4. Install a local project in “editable” mode. See the section on Editable Installs.

    Unix/macOS

    1. python -m pip install -e .                # project in current directory
    2. python -m pip install -e path/to/project  # project in another directory

    Windows

    1. py -m pip install -e .                 # project in current directory
    2. py -m pip install -e path/to/project   # project in another directory

  5. Install a project from VCS

    Unix/macOS

    1. python -m pip install SomeProject@git+https://git.repo/some_pkg.git@1.3.1

    Windows

    1. py -m pip install SomeProject@git+https://git.repo/some_pkg.git@1.3.1

  6. Install a project from VCS in “editable” mode. See the sections on VCS Support and Editable Installs.

    Unix/macOS

    1. python -m pip install -e git+https://git.repo/some_pkg.git#egg=SomePackage          # from git
    2. python -m pip install -e hg+https://hg.repo/some_pkg.git#egg=SomePackage            # from mercurial
    3. python -m python -m pip install -e svn+svn://svn.repo/some_pkg/trunk/#egg=SomePackage         # from svn
    4. python -m pip install -e git+https://git.repo/some_pkg.git@feature#egg=SomePackage  # from 'feature' branch
    5. 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

    Windows

    1. py -m pip install -e git+https://git.repo/some_pkg.git#egg=SomePackage          # from git
    2. py -m pip install -e hg+https://hg.repo/some_pkg.git#egg=SomePackage            # from mercurial
    3. py -m pip install -e svn+svn://svn.repo/some_pkg/trunk/#egg=SomePackage         # from svn
    4. py -m pip install -e git+https://git.repo/some_pkg.git@feature#egg=SomePackage  # from 'feature' branch
    5. 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

  7. Install a package with setuptools extras.

    Unix/macOS

    1. python -m pip install SomePackage[PDF]
    2. python -m pip install "SomePackage[PDF] @ git+https://git.repo/SomePackage@master#subdirectory=subdir_path"
    3. python -m pip install .[PDF]  # project in current directory
    4. python -m pip install SomePackage[PDF]==3.0
    5. python -m pip install SomePackage[PDF,EPUB]  # multiple extras

    Windows

    1. py -m pip install SomePackage[PDF]
    2. py -m pip install "SomePackage[PDF] @ git+https://git.repo/SomePackage@master#subdirectory=subdir_path"
    3. py -m pip install .[PDF]  # project in current directory
    4. py -m pip install SomePackage[PDF]==3.0
    5. py -m pip install SomePackage[PDF,EPUB]  # multiple extras

  8. Install a particular source archive file.

    Unix/macOS

    1. python -m pip install ./downloads/SomePackage-1.0.4.tar.gz
    2. python -m pip install http://my.package.repo/SomePackage-1.0.4.zip

    Windows

    1. py -m pip install ./downloads/SomePackage-1.0.4.tar.gz
    2. py -m pip install http://my.package.repo/SomePackage-1.0.4.zip

  9. Install a particular source archive file following PEP 440 direct references.

    Unix/macOS

    1. python -m pip install SomeProject@http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl
    2. python -m pip install "SomeProject @ http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl"
    3. python -m pip install SomeProject@http://my.package.repo/1.2.3.tar.gz

    Windows

    1. py -m pip install SomeProject@http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl
    2. py -m pip install "SomeProject @ http://my.package.repo/SomeProject-1.2.3-py33-none-any.whl"
    3. py -m pip install SomeProject@http://my.package.repo/1.2.3.tar.gz

  10. Install from alternative package repositories.

    Install from a different index, and not PyPI

    Unix/macOS

    1. python -m pip install --index-url http://my.package.repo/simple/ SomePackage

    Windows

    1. py -m pip install --index-url http://my.package.repo/simple/ SomePackage

    Search an additional index during install, in addition to PyPI

    Unix/macOS

    1. python -m pip install --extra-index-url http://my.package.repo/simple SomePackage

    Windows

    1. py -m pip install --extra-index-url http://my.package.repo/simple SomePackage

    Install from a local flat directory containing archives (and don’t scan indexes):

    Unix/macOS

    1. python -m pip install --no-index --find-links=file:///local/dir/ SomePackage
    2. python -m pip install --no-index --find-links=/local/dir/ SomePackage
    3. python -m pip install --no-index --find-links=relative/dir/ SomePackage

    Windows

    1. py -m pip install --no-index --find-links=file:///local/dir/ SomePackage
    2. py -m pip install --no-index --find-links=/local/dir/ SomePackage
    3. py -m pip install --no-index --find-links=relative/dir/ SomePackage

  11. Find pre-release and development versions, in addition to stable versions. By default, pip only finds stable versions.

    Unix/macOS

    1. python -m pip install --pre SomePackage

    Windows

    1. py -m pip install --pre SomePackage

  12. Install packages from source.

    Do not use any binary packages

    Unix/macOS

    1. python -m pip install SomePackage1 SomePackage2 --no-binary :all:

    Windows

    1. py -m pip install SomePackage1 SomePackage2 --no-binary :all:

    Specify SomePackage1 to be installed from source:

    Unix/macOS

    1. python -m pip install SomePackage1 SomePackage2 --no-binary SomePackage1

    Windows

    1. py -m pip install SomePackage1 SomePackage2 --no-binary SomePackage1

1

This is true with the exception that pip v7.0 and v7.0.1 required quotes around specifiers containing environment markers in requirement files.

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_install.%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?