This guide discusses how to install packages using pip and
a virtual environment manager: either venv for Python 3 or virtualenv
for Python 2. These are the lowest-level tools for managing Python
packages and are recommended if higher-level tools do not suit your needs.
Note
This doc uses the term package to refer to a
Distribution Package which is different from an Import
Package that which is used to import modules in your Python source code.
Installing pip¶
pip is the reference Python package manager. It’s used to install and
update packages. You’ll need to make sure you have the latest version of pip
installed.
Unix/macOS
Debian and most other distributions include a python-pip package; if you
want to use the Linux distribution-provided versions of pip, see
Installing pip/setuptools/wheel with Linux Package Managers.
You can also install pip yourself to ensure you have the latest version. It’s
recommended to use the system pip to bootstrap a user installation of pip:
python3 -m pip install --user --upgrade pip python3 -m pip --version
Afterwards, you should have the latest version of pip installed in your
user site:
pip 21.1.3 from $HOME/.local/lib/python3.9/site-packages (python 3.9)
Windows
The Python installers for Windows include pip. You can make sure that pip is
up-to-date by running:
py -m pip install --upgrade pip py -m pip --version
Afterwards, you should have the latest version of pip:
pip 21.1.3 from c:\python39\lib\site-packages (Python 3.9.4)
Installing virtualenv¶
Note
If you are using Python 3.3 or newer, the venv
module is
the preferred way to create and manage virtual environments.
venv is included in the Python standard library and requires no additional installation.
If you are using venv, you may skip this section.
virtualenv is used to manage Python packages for different projects.
Using virtualenv allows you to avoid installing Python packages globally
which could break system tools or other projects. You can install virtualenv
using pip.
Unix/macOS
python3 -m pip install --user virtualenv
Windows
py -m pip install --user virtualenv
Creating a virtual environment¶
venv (for Python 3) and virtualenv (for Python 2) allow
you to manage separate package installations for
different projects. They essentially allow you to create a “virtual” isolated
Python installation and install packages into that virtual installation. When
you switch projects, you can simply create a new virtual environment and not
have to worry about breaking the packages installed in the other environments.
It is always recommended to use a virtual environment while developing Python
applications.
To create a virtual environment, go to your project’s directory and run
venv. If you are using Python 2, replace venv
with virtualenv
in the below commands.
The second argument is the location to create the virtual environment. Generally, you
can just create this in your project and call it env
.
venv will create a virtual Python installation in the env
folder.
Note
You should exclude your virtual environment directory from your version
control system using .gitignore
or similar.
Activating a virtual environment¶
Before you can start installing or using packages in your virtual environment you’ll
need to activate it. Activating a virtual environment will put the
virtual environment-specific
python
and pip
executables into your shell’s PATH
.
You can confirm you’re in the virtual environment by checking the location of your
Python interpreter:
It should be in the env
directory:
Unix/macOS
Windows
...\env\Scripts\python.exe
As long as your virtual environment is activated pip will install packages into that
specific environment and you’ll be able to import and use packages in your
Python application.
Leaving the virtual environment¶
If you want to switch projects or otherwise leave your virtual environment, simply run:
If you want to re-enter the virtual environment just follow the same instructions above
about activating a virtual environment. There’s no need to re-create the virtual environment.
Installing packages¶
Now that you’re in your virtual environment you can install packages. Let’s install the
Requests library from the Python Package Index (PyPI):
Unix/macOS
python3 -m pip install requests
Windows
py -m pip install requests
pip should download requests and all of its dependencies and install them:
Collecting requests Using cached requests-2.18.4-py2.py3-none-any.whl Collecting chardet<3.1.0,>=3.0.2 (from requests) Using cached chardet-3.0.4-py2.py3-none-any.whl Collecting urllib3<1.23,>=1.21.1 (from requests) Using cached urllib3-1.22-py2.py3-none-any.whl Collecting certifi>=2017.4.17 (from requests) Using cached certifi-2017.7.27.1-py2.py3-none-any.whl Collecting idna<2.7,>=2.5 (from requests) Using cached idna-2.6-py2.py3-none-any.whl Installing collected packages: chardet, urllib3, certifi, idna, requests Successfully installed certifi-2017.7.27.1 chardet-3.0.4 idna-2.6 requests-2.18.4 urllib3-1.22
Installing specific versions¶
pip allows you to specify which version of a package to install using
version specifiers. For example, to install
a specific version of requests
:
Unix/macOS
python3 -m pip install 'requests==2.18.4'
Windows
py -m pip install "requests==2.18.4"
To install the latest 2.x
release of requests:
Unix/macOS
python3 -m pip install 'requests>=2.0.0,<3.0.0'
Windows
py -m pip install "requests>=2.0.0,<3.0.0"
To install pre-release versions of packages, use the --pre
flag:
Unix/macOS
python3 -m pip install --pre requests
Windows
py -m pip install --pre requests
Installing from source¶
pip can install a package directly from source, for example:
Unix/macOS
cd google-auth python3 -m pip install .
Windows
cd google-auth
py -m pip install .
Additionally, pip can install packages from source in
development mode,
meaning that changes to the source directory will immediately affect the
installed package without needing to re-install:
Unix/macOS
python3 -m pip install --editable .
Windows
py -m pip install --editable .
Installing from version control systems¶
pip can install packages directly from their version control system. For
example, you can install directly from a git repository:
google-auth @ git+https://github.com/GoogleCloudPlatform/google-auth-library-python.git
For more information on supported version control systems and syntax, see pip’s
documentation on VCS Support.
Installing from local archives¶
If you have a local copy of a Distribution Package’s archive (a zip,
wheel, or tar file) you can install it directly with pip:
Unix/macOS
python3 -m pip install requests-2.18.4.tar.gz
Windows
py -m pip install requests-2.18.4.tar.gz
If you have a directory containing archives of multiple packages, you can tell
pip to look for packages there and not to use the
Python Package Index (PyPI) at all:
Unix/macOS
python3 -m pip install --no-index --find-links=/local/dir/ requests
Windows
py -m pip install --no-index --find-links=/local/dir/ requests
This is useful if you are installing packages on a system with limited
connectivity or if you want to strictly control the origin of distribution
packages.
Using other package indexes¶
If you want to download packages from a different index than the
Python Package Index (PyPI), you can use the --index-url
flag:
Unix/macOS
python3 -m pip install --index-url http://index.example.com/simple/ SomeProject
Windows
py -m pip install --index-url http://index.example.com/simple/ SomeProject
If you want to allow packages from both the Python Package Index (PyPI)
and a separate index, you can use the --extra-index-url
flag instead:
Unix/macOS
python3 -m pip install --extra-index-url http://index.example.com/simple/ SomeProject
Windows
py -m pip install --extra-index-url http://index.example.com/simple/ SomeProject
Upgrading packages¶
pip can upgrade packages in-place using the --upgrade
flag. For example, to
install the latest version of requests
and all of its dependencies:
Unix/macOS
python3 -m pip install --upgrade requests
Windows
py -m pip install --upgrade requests
Using requirements files¶
Instead of installing packages individually, pip allows you to declare all
dependencies in a Requirements File. For
example you could create a requirements.txt
file containing:
requests==2.18.4 google-auth==1.1.0
And tell pip to install all of the packages in this file using the -r
flag:
Unix/macOS
python3 -m pip install -r requirements.txt
Windows
py -m pip install -r requirements.txt
Freezing dependencies¶
Pip can export a list of all installed packages and their versions using the
freeze
command:
Which will output a list of package specifiers such as:
cachetools==2.0.1 certifi==2017.7.27.1 chardet==3.0.4 google-auth==1.1.1 idna==2.6 pyasn1==0.3.6 pyasn1-modules==0.1.4 requests==2.18.4 rsa==3.4.2 six==1.11.0 urllib3==1.22
This is useful for creating Requirements Files that can re-create
the exact versions of all packages installed in an environment.
Usage#
Unix/macOS
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> ...
Windows
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> ...
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:
-
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).
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:
-
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.
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).
Obtaining information about what was installed#
The install command has a --report
option that will generate a JSON report of what
pip has installed. In combination with the --dry-run
and --ignore-installed
it
can be used to resolve a set of requirements without actually installing them.
The report can be written to a file, or to standard output (using --report -
in
combination with --quiet
).
The format of the JSON report is described in Installation Report.
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
$ python -m pip install quux ... Installing collected packages baz, bar, foo, quux $ python -m pip install bar ... Installing collected packages foo, baz, bar
Windows
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
profile:
-
They have build dependencies that are also declared as install dependencies
usinginstall_requires
. -
python setup.py egg_info
works without their build dependencies being
installed. -
For whatever reason, they don’t or won’t declare their build dependencies using
setup_requires
.
Requirements File Format
This section has been moved to Requirements File Format.
Requirement Specifiers
This section has been moved to Requirement Specifiers.
Per-requirement Overrides
This is now covered in Requirements File Format.
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
This is now covered in VCS Support.
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
This is now covered in HTTPS Certificates.
Caching
This is now covered in Caching.
Wheel Cache
This is now covered in Caching.
Hash checking mode
This is now covered in Secure installs.
Local Project Installs
This is now covered in Local project installs.
Editable installs
This is now covered in Local project installs.
Build System Interface
This is now covered in Build System Interface.
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.
- —dry-run#
-
Don’t actually install anything, just print what would be. Can be used in combination with —ignore-installed to ‘resolve’ the requirements.
- -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. Note that the resulting installation may contain scripts and other resources which reference the Python interpreter of pip, and not that of
--prefix
. See also the--python
option if the intention is to install packages into another (possibly pip-free) environment.
- —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).
- —check-build-dependencies#
-
Check the build dependencies when PEP517 is used.
- —break-system-packages#
-
Allow pip to modify an EXTERNALLY-MANAGED Python installation
- -C, —config-settings <settings>#
-
Configuration settings to be passed to the PEP 517 build backend. Settings take the form KEY=VALUE. Use multiple —config-settings options to pass multiple keys to the backend.
- —global-option <options>#
-
Extra global options to be supplied to the setup.py call before the install or bdist_wheel 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 whether the progress bar should be used [on, off] (default: on)
- —root-user-action <root_user_action>#
-
Action if pip is run as a root user. By default, a warning message is shown.
- —report <file>#
-
Generate a JSON file describing what pip did to install the provided requirements. Can be used in combination with —dry-run and —ignore-installed to ‘resolve’ the requirements. When — is used as file name it writes to stdout. When writing to stdout, please combine with the —quiet option to avoid mixing pip logging output with JSON output.
- —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 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#
-
Install
SomePackage
and its dependencies from PyPI using Requirement SpecifiersUnix/macOS
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
Windows
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.
Unix/macOS
python -m pip install -r requirements.txt
Windows
py -m pip install -r requirements.txt
-
Upgrade an already installed
SomePackage
to the latest from PyPI.Unix/macOS
python -m pip install --upgrade SomePackage
Windows
py -m pip install --upgrade SomePackage
Note
This will guarantee an update to
SomePackage
as it is a direct
requirement, and possibly upgrade dependencies if their installed
versions do not meet the minimum requirements ofSomePackage
.
Any non-requisite updates of its dependencies (indirect requirements)
will be affected by the--upgrade-strategy
command. -
Install a local project in “editable” mode. See the section on Editable Installs.
Unix/macOS
python -m pip install -e . # project in current directory python -m pip install -e path/to/project # project in another directory
Windows
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
Unix/macOS
python -m pip install 'SomeProject@git+https://git.repo/some_pkg.git@1.3.1'
Windows
py -m pip install "SomeProject@git+https://git.repo/some_pkg.git@1.3.1"
-
Install a project from VCS in “editable” mode. See the sections on VCS Support and Editable Installs.
Unix/macOS
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
Windows
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 extras.
Unix/macOS
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
Windows
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.
Unix/macOS
python -m pip install './downloads/SomePackage-1.0.4.tar.gz' python -m pip install 'http://my.package.repo/SomePackage-1.0.4.zip'
Windows
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.
Unix/macOS
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'
Windows
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
Unix/macOS
python -m pip install --index-url http://my.package.repo/simple/ SomePackage
Windows
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):
Unix/macOS
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
Windows
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
Warning
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.Unix/macOS
python -m pip install --extra-index-url http://my.package.repo/simple SomePackage
Windows
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.
Unix/macOS
python -m pip install --pre SomePackage
Windows
py -m pip install --pre SomePackage
-
Install packages from source.
Do not use any binary packages
Unix/macOS
python -m pip install SomePackage1 SomePackage2 --no-binary :all:
Windows
py -m pip install SomePackage1 SomePackage2 --no-binary :all:
Specify
SomePackage1
to be installed from source:Unix/macOS
python -m pip install SomePackage1 SomePackage2 --no-binary SomePackage1
Windows
py -m pip install SomePackage1 SomePackage2 --no-binary SomePackage1
Что представляют собой пакеты и модули, откуда их брать и что с ними делать.
https://gbcdn.mrgcdn.ru/uploads/post/1340/og_cover_image/a9b1c9e84cf2c603aa80f227403c4177
Прежде чем что-то устанавливать, давайте разберёмся, что такое пакет, чем он отличается от модуля, и как с ним работать. У слова «пакет» применительно к Python два значения.
C одной стороны, пакеты Python — это Py-приложения, дополнения или утилиты, которые можно установить из внешнего репозитория: Github, Bitbucket, Google Code или официального Python Package Index. На сервере пакеты хранятся в .zip и .tar архивах, либо в дополнительной упаковке — «яйцах» (.egg, старый формат) или «колесах» (.whl). В составе пакета, как правило, есть сценарий установки setup.py, который хранит сведения о зависимостях — других пакетах и модулях, без которых пакет работать не будет.
С другой стороны, если речь об архитектуре Python-приложения, пакет — это каталог, внутри которого файл __init__.py и, опционально, другие каталоги и файлы .py. Так большую Python-программу разбивают на пакеты и модули. Модуль — файл с исходным кодом, который можно использовать в других приложениях: как «заготовку» для будущих проектов или как часть библиотеки/фреймворка. Но к теме статьи это прямого отношения не имеет, поэтому дальше мы будем говорить только о пакетах из репозиториев.
Чтобы за секунды устанавливать пакеты со всеми зависимостями, используют менеджер пакетов pip или модуль easy_install. В большинстве случаев рекомендуется использовать pip. И только если у вас есть инфраструктура на пакетах .egg, которые pip не открывает, нужен easy_install.
Установка PIP для Python 3 и 2
Если вы используете виртуальные окружения на базе venv или virtualenv, pip уже установлен. Начиная с Python 3.4 (для Python 2 — с версии 2.7.9) pip поставляется вместе с интерпретатором. Для более ранних версий устанавливать менеджер пакетов нужно вручную. Вариантов два:
-
C помощью скрипта get_pip.py — быстро.
-
Через setuptools — кроме pip сможем использовать easy_install.
Вариант 1. Скачиваем скрипт get_pip.py и запускаем в консоли. Для этого открываем терминал через Win+R>»cmd»>OK и пишем:
python get_pip.py
Остальное установщик сделает сам: если нужно, попутно установит wheel (для распаковки .whl-колес) и setuptools. Чтобы запретить инсталляцию дополнительных инструментов, можно добавить в строку ключи —no-setuptools и/или —no-wheels.
Если возникает ошибка, путь к Python не прописан в переменной среды $PATH. Нужно либо найти эту переменную в системном реестре и задать её значение, либо каждый раз указывать полный путь до python.exe, а за ним уже имя исполняемого Py-файла:
C:/python32/python.exe get_pip.py
Полный путь полезен и в том случае, если у вас на компьютере несколько версий Python и вы ставите пакет для одной из них.
Вариант 2. Скачиваем архив с setuptools из PYPI и распаковываем в отдельный каталог. В терминале переходим в директорию setuptools c файлом setup.py и пишем:
python setup.py install
Обновить pip для Python в Windows можно так:
python pip install -U pip
Если это не работает, нужно добавить путь к папке с pip в $PATH.
Установка пакета в pip
Пора запустить pip в Python и начать устанавливать пакеты короткой командой из консоли:
pip install имя_пакета
При установке в Windows, перед pip нужно добавить «python -m».
Обновить пакет не сложнее:
pip install имя_пакета -U
Если у вас последняя версия пакета, но вы хотите принудительно переустановить его:
pip install --force-reinstall
Посмотреть список установленных пакетов Python можно с помощью команды:
pip list
Найти конкретный пакет по имени можно командой «pip search». О других командах можно прочесть в справке, которая выдается по команде «pip help».
Удаление пакета Python
Когда пакет больше не нужен, пишем:
pip uninstall имя_пакета
Как установить пакеты в Python без pip
Формат .egg сейчас используют не часто, поэтому pip его не поддерживает. Модуль easy_install умеет устанавливать как .egg, так и обычные пакеты, но есть у него важные минусы:
-
он не удаляет пакеты,
-
он может пытаться установить недозагруженный пакет.
Использовать easy_install можно сразу после установки setuptools. Хранится модуль в папке Scripts вашего интерпретатора. Если у вас в $PATH верно прописан путь, ставить пакеты из PYPI можно короткой командой:
easy_install имя_пакета
Для обновления после install и перед именем пакета нужно ставить ключ -U. Откатиться до нужной версии можно так:
easy_install имя_пакета=0.2.3
Если нужно скачать пакет из альтернативного источника, вы можете задать URL или локальный адрес на компьютере:
easy_install http://адрес_репозитория.ру/директория/пакет-1.1.2.zip
Чтобы узнать об опциях easy_install, запустим его с ключом -h:
easy_install -h
Список пакетов, установленных через easy_install, хранится в файле easy-install.pth в директории /libs/site-packages/ вашего Python.
К счастью, удалять установленные через easy_install пакеты можно с помощью pip. Если же его нет, потребуется удалить пакет вручную и стереть сведения о нем из easy-install.pth.
Теперь вы умеете ставить и удалять пакеты для вашей версии Python.
Кстати, для тех, кто изучает Python, мы подготовили список полезных и практичных советов.
Pip — консольный менеджер пакетов для Python. Рассказываем как его установить, и какие возможности управления пакетами он предоставляет.
Pip — менеджер пакетов для Python, работа с ним осуществляется через командную строку. Pip не нужно устанавливать отдельно, если вы пользуетесь Python версии 2.7.9 и новее или версии 3.4 и новее. Если pip установлен, то можно ввести в командную строку:
Команды статье указаны для Windows, работа с pip в Linux может отличаться.
Вы получите справку по основным командам.
Установка pip для Python
Если pip не установлен, то нужно скачать скрипт. Выбирайте папку с номером вашей версии Python. После этого в командной строке перейдите в папку со скриптом и выполните команду:
Если pip установлен в папку ProgramFiles, то вам нужно запускать командную строку от администратора.
Если вы установили pip, но все равно получаете ошибку в консоли, нужно указать путь к файлу pip.exe в переменной Path. Для этого зайдите в свойства компьютера>Дополнительные параметры системы>Переменные среды. Здесь (в зависимости о версии Windows) либо добавьте путь к уже существующему через точку с запятой, либо просто нажмите создать и скопируйте путь в новое поле.
Если вам нужно обновить pip напишите в командной строке:
python -m pip install --upgrade pip
Управление пакетами
Чтобы выполнить установку пакета с сайта pypi.org введите в консоли:
python -m pip install ИмяПакета
Если вам нужно использовать несколько версий pip, то нужную можно указать так (начиная с версии pip 0.8):
pip-0.8 install ИмяПакета
Таким же образом можно выбирать версию Python:
python-3.6 -m pip install ИмяПакета
Pip версии 1.5 и выше следует указывать так:
Чтобы обновить пакет введите:
python -m pip install --upgrade ИмяПакета
Для удаления пакета используйте команду uninstall:
python -m pip uninstall ИмяПакета
Флаг -m используется для того чтобы запустить установленный модуль, как скрипт (если написать pip без -m вы можете получить ошибку).
Вывести список всех установленных пакетов в файл можно с помощью :
pip freeze > requirements.txt // название файла может быть любым
При наличии такого файла, можно устанавливать пакеты группами:
pip install -r requirements.txt// версии пакетов в файле указывать не обязательно
Необходимые пакеты можно найти не заходя на сайт pyPi.org (в данный момент недоступно):
pip search строка для поиска
Чтобы узнать подробности об установленном пакете введите:
Проверить установлены ли все зависимости для ваших пакетов можно так:
Теперь, с этими знаниями, вы можете самостоятельно скачать пакет cowsay, зайти в python, и ввести этот текст:
>>> import cowsay
>>> cowsay.cow('Я умею работать с pip! Му!')
Готово! У вас есть говорящая консольная корова:
Contents
- User Guide
- Installing Packages
- Requirements Files
- Constraints Files
- Installing from Wheels
- Uninstalling Packages
- Listing Packages
- Searching for Packages
- Configuration
- Config file
- Environment Variables
- Config Precedence
- Command Completion
- Installing from local packages
- «Only if needed» Recursive Upgrade
- User Installs
- Ensuring Repeatability
- Pinned Version Numbers
- Hash-checking Mode
- Installation Bundles
Installing Packages¶
pip supports installing from PyPI, version control, local projects, and
directly from distribution files.
The most common scenario is to install from PyPI using Requirement Specifiers
$ pip install SomePackage # latest version $ pip install SomePackage==1.0.4 # specific version $ pip install 'SomePackage>=1.0.4' # minimum version
For more information and examples, see the pip install reference.
Requirements Files¶
«Requirements files» are files containing a list of items to be
installed using pip install like so:
pip install -r requirements.txt
Details on the format of the files are here: Requirements File Format.
Logically, a Requirements file is just a list of pip install arguments
placed in a file. Note that you should not rely on the items in the file being
installed by pip in any particular order.
In practice, there are 4 common uses of Requirements files:
-
Requirements files are used to hold the result from pip freeze for the
purpose of achieving repeatable installations. In
this case, your requirement file contains a pinned version of everything that
was installed when pip freeze was run.pip freeze > requirements.txt pip install -r requirements.txt
-
Requirements files are used to force pip to properly resolve dependencies.
As it is now, pip doesn’t have true dependency resolution, but instead simply uses the first
specification it finds for a project. E.g if pkg1 requires pkg3>=1.0 and
pkg2 requires pkg3>=1.0,<=2.0, and if pkg1 is resolved first, pip will
only use pkg3>=1.0, and could easily end up installing a version of pkg3
that conflicts with the needs of pkg2. To solve this problem, you can
place pkg3>=1.0,<=2.0 (i.e. the correct specification) into your
requirements file directly along with the other top level requirements. Like
so:pkg1 pkg2 pkg3>=1.0,<=2.0
-
Requirements files are used to force pip to install an alternate version of a
sub-dependency. For example, suppose ProjectA in your requirements file
requires ProjectB, but the latest version (v1.3) has a bug, you can force
pip to accept earlier versions like so: -
Requirements files are used to override a dependency with a local patch that
lives in version control. For example, suppose a dependency,
SomeDependency from PyPI has a bug, and you can’t wait for an upstream fix.
You could clone/copy the src, make the fix, and place it in VCS with the tag
sometag. You’d reference it in your requirements file with a line like so:git+https://myvcs.com/some_dependency@sometag#egg=SomeDependency
If SomeDependency was previously a top-level requirement in your
requirements file, then replace that line with the new line. If
SomeDependency is a sub-dependency, then add the new line.
It’s important to be clear that pip determines package dependencies using
install_requires metadata,
not by discovering requirements.txt files embedded in projects.
See also:
- Requirements File Format
- pip freeze
- «setup.py vs requirements.txt» (an article by Donald Stufft)
Constraints Files¶
Constraints files are requirements files that only control which version of a
requirement is installed, not whether it is installed or not. Their syntax and
contents is nearly identical to Requirements Files. There is one key
difference: Including a package in a constraints file does not trigger
installation of the package.
Use a constraints file like so:
pip install -c constraints.txt
Constraints files are used for exactly the same reason as requirements files
when you don’t know exactly what things you want to install. For instance, say
that the «helloworld» package doesn’t work in your environment, so you have a
local patched version. Some things you install depend on «helloworld», and some
don’t.
One way to ensure that the patched version is used consistently is to
manually audit the dependencies of everything you install, and if «helloworld»
is present, write a requirements file to use when installing that thing.
Constraints files offer a better way: write a single constraints file for your
organisation and use that everywhere. If the thing being installed requires
«helloworld» to be installed, your fixed version specified in your constraints
file will be used.
Constraints file support was added in pip 7.1.
Installing from Wheels¶
«Wheel» is a built, archive format that can greatly speed installation compared
to building and installing from source archives. For more information, see the
Wheel docs ,
PEP427, and
PEP425
Pip prefers Wheels where they are available. To disable this, use the
—no-binary flag for pip install.
If no satisfactory wheels are found, pip will default to finding source archives.
To install directly from a wheel archive:
pip install SomePackage-1.0-py2.py3-none-any.whl
For the cases where wheels are not available, pip offers pip wheel as a
convenience, to build wheels for all your requirements and dependencies.
pip wheel requires the wheel package to be installed, which provides the
«bdist_wheel» setuptools extension that it uses.
To build wheels for your requirements and all their dependencies to a local directory:
pip install wheel pip wheel --wheel-dir=/local/wheels -r requirements.txt
And then to install those requirements just using your local directory of wheels (and not from PyPI):
pip install --no-index --find-links=/local/wheels -r requirements.txt
Uninstalling Packages¶
pip is able to uninstall most packages like so:
$ pip uninstall SomePackage
pip also performs an automatic uninstall of an old version of a package
before upgrading to a newer version.
For more information and examples, see the pip uninstall reference.
Listing Packages¶
To list installed packages:
$ pip list docutils (0.9.1) Jinja2 (2.6) Pygments (1.5) Sphinx (1.1.2)
To list outdated packages, and show the latest version available:
$ pip list --outdated docutils (Current: 0.9.1 Latest: 0.10) Sphinx (Current: 1.1.2 Latest: 1.1.3)
To show details about an installed package:
$ pip show sphinx --- Name: Sphinx Version: 1.1.3 Location: /my/env/lib/pythonx.x/site-packages Requires: Pygments, Jinja2, docutils
For more information and examples, see the pip list and pip show
reference pages.
Searching for Packages¶
pip can search PyPI for packages using the pip search
command:
The query will be used to search the names and summaries of all
packages.
For more information and examples, see the pip search reference.
Configuration¶
Config file¶
pip allows you to set all command line option defaults in a standard ini
style config file.
The names and locations of the configuration files vary slightly across
platforms. You may have per-user, per-virtualenv or site-wide (shared amongst
all users) configuration:
Per-user:
- On Unix the default configuration file is:
$HOME/.config/pip/pip.conf
which respects theXDG_CONFIG_HOME
environment variable. - On macOS the configuration file is
$HOME/Library/Application Support/pip/pip.conf
. - On Windows the configuration file is
%APPDATA%\pip\pip.ini
.
There are also a legacy per-user configuration file which is also respected,
these are located at:
- On Unix and macOS the configuration file is:
$HOME/.pip/pip.conf
- On Windows the configuration file is:
%HOME%\pip\pip.ini
You can set a custom path location for this config file using the environment
variable PIP_CONFIG_FILE
.
Inside a virtualenv:
- On Unix and macOS the file is
$VIRTUAL_ENV/pip.conf
- On Windows the file is:
%VIRTUAL_ENV%\pip.ini
Site-wide:
- On Unix the file may be located in
/etc/pip.conf
. Alternatively
it may be in a «pip» subdirectory of any of the paths set in the
environment variableXDG_CONFIG_DIRS
(if it exists), for example
/etc/xdg/pip/pip.conf
. - On macOS the file is:
/Library/Application Support/pip/pip.conf
- On Windows XP the file is:
C:\Documents and Settings\All Users\Application Data\pip\pip.ini
- On Windows 7 and later the file is hidden, but writeable at
C:\ProgramData\pip\pip.ini
- Site-wide configuration is not supported on Windows Vista
If multiple configuration files are found by pip then they are combined in
the following order:
- Firstly the site-wide file is read, then
- The per-user file is read, and finally
- The virtualenv-specific file is read.
Each file read overrides any values read from previous files, so if the
global timeout is specified in both the site-wide file and the per-user file
then the latter value is the one that will be used.
The names of the settings are derived from the long command line option, e.g.
if you want to use a different package index (--index-url
) and set the
HTTP timeout (--default-timeout
) to 60 seconds your config file would
look like this:
[global] timeout = 60 index-url = http://download.zope.org/ppix
Each subcommand can be configured optionally in its own section so that every
global setting with the same name will be overridden; e.g. decreasing the
timeout
to 10
seconds when running the freeze
(Freezing Requirements) command and using
60
seconds for all other commands is possible with:
[global] timeout = 60 [freeze] timeout = 10
Boolean options like --ignore-installed
or --no-dependencies
can be
set like this:
[install] ignore-installed = true no-dependencies = yes
To enable the boolean options --no-compile
and --no-cache-dir
, falsy
values have to be used:
[global] no-cache-dir = false [install] no-compile = no
Appending options like --find-links
can be written on multiple lines:
[global] find-links = http://download.example.com [install] find-links = http://mirror1.example.com http://mirror2.example.com
Environment Variables¶
pip’s command line options can be set with environment variables using the
format PIP_<UPPER_LONG_NAME>
. Dashes (-
) have to be replaced with
underscores (_
).
For example, to set the default timeout:
export PIP_DEFAULT_TIMEOUT=60
This is the same as passing the option to pip directly:
pip --default-timeout=60 [...]
To set options that can be set multiple times on the command line, just add
spaces in between values. For example:
export PIP_FIND_LINKS="http://mirror1.example.com http://mirror2.example.com"
is the same as calling:
pip install --find-links=http://mirror1.example.com --find-links=http://mirror2.example.com
Config Precedence¶
Command line options have precedence over environment variables, which have precedence over the config file.
Within the config file, command specific sections have precedence over the global section.
Examples:
--host=foo
overridesPIP_HOST=foo
PIP_HOST=foo
overrides a config file with[global] host = foo
- A command specific section in the config file
[<command>] host = bar
overrides the option with same name in the[global]
config file section
Command Completion¶
pip comes with support for command line completion in bash, zsh and fish.
To setup for bash:
$ pip completion --bash >> ~/.profile
To setup for zsh:
$ pip completion --zsh >> ~/.zprofile
To setup for fish:
$ pip completion --fish > ~/.config/fish/completions/pip.fish
Alternatively, you can use the result of the completion
command
directly with the eval function of your shell, e.g. by adding the following to your startup file:
eval "`pip completion --bash`"
Installing from local packages¶
In some cases, you may want to install from local packages only, with no traffic
to PyPI.
First, download the archives that fulfill your requirements:
$ pip install --download DIR -r requirements.txt
Note that pip install --download
will look in your wheel cache first, before
trying to download from PyPI. If you’ve never installed your requirements
before, you won’t have a wheel cache for those items. In that case, if some of
your requirements don’t come as wheels from PyPI, and you want wheels, then run
this instead:
$ pip wheel --wheel-dir DIR -r requirements.txt
Then, to install from local only, you’ll be using —find-links and —no-index like so:
$ pip install --no-index --find-links=DIR -r requirements.txt
«Only if needed» Recursive Upgrade¶
pip install --upgrade
is currently written to perform an eager recursive
upgrade, i.e. it upgrades all dependencies regardless of whether they still
satisfy the new parent requirements.
E.g. supposing:
- SomePackage-1.0 requires AnotherPackage>=1.0
- SomePackage-2.0 requires AnotherPackage>=1.0 and OneMorePackage==1.0
- SomePackage-1.0 and AnotherPackage-1.0 are currently installed
- SomePackage-2.0 and AnotherPackage-2.0 are the latest versions available on PyPI.
Running pip install --upgrade SomePackage
would upgrade SomePackage and
AnotherPackage despite AnotherPackage already being satisfied.
pip doesn’t currently have an option to do an «only if needed» recursive
upgrade, but you can achieve it using these 2 steps:
pip install --upgrade --no-deps SomePackage pip install SomePackage
The first line will upgrade SomePackage, but not dependencies like
AnotherPackage. The 2nd line will fill in new dependencies like
OneMorePackage.
See #59 for a plan of making «only if needed» recursive the default
behavior for a new pip upgrade
command.
User Installs¶
With Python 2.6 came the «user scheme» for installation,
which means that all Python distributions support an alternative install
location that is specific to a user. The default location for each OS is
explained in the python documentation for the site.USER_BASE variable. This mode
of installation can be turned on by specifying the —user option to pip install
.
Moreover, the «user scheme» can be customized by setting the
PYTHONUSERBASE
environment variable, which updates the value of site.USER_BASE
.
To install «SomePackage» into an environment with site.USER_BASE customized to ‘/myappenv’, do the following:
export PYTHONUSERBASE=/myappenv pip install --user SomePackage
pip install --user
follows four rules:
- When globally installed packages are on the python path, and they conflict
with the installation requirements, they are ignored, and not
uninstalled. - When globally installed packages are on the python path, and they satisfy
the installation requirements, pip does nothing, and reports that
requirement is satisfied (similar to how global packages can satisfy
requirements when installing packages in a--system-site-packages
virtualenv). - pip will not perform a
--user
install in a--no-site-packages
virtualenv (i.e. the default kind of virtualenv), due to the user site not
being on the python path. The installation would be pointless. - In a
--system-site-packages
virtualenv, pip will not install a package
that conflicts with a package in the virtualenv site-packages. The —user
installation would lack sys.path precedence and be pointless.
To make the rules clearer, here are some examples:
From within a --no-site-packages
virtualenv (i.e. the default kind):
$ pip install --user SomePackage Can not perform a '--user' install. User site-packages are not visible in this virtualenv.
From within a --system-site-packages
virtualenv where SomePackage==0.3
is already installed in the virtualenv:
$ pip install --user SomePackage==0.4 Will not install to the user site because it will lack sys.path precedence
From within a real python, where SomePackage
is not installed globally:
$ pip install --user SomePackage [...] Successfully installed SomePackage
From within a real python, where SomePackage
is installed globally, but is not the latest version:
$ pip install --user SomePackage [...] Requirement already satisfied (use --upgrade to upgrade) $ pip install --user --upgrade SomePackage [...] Successfully installed SomePackage
From within a real python, where SomePackage
is installed globally, and is the latest version:
$ pip install --user SomePackage [...] Requirement already satisfied (use --upgrade to upgrade) $ pip install --user --upgrade SomePackage [...] Requirement already up-to-date: SomePackage # force the install $ pip install --user --ignore-installed SomePackage [...] Successfully installed SomePackage
Ensuring Repeatability¶
pip can achieve various levels of repeatability:
Pinned Version Numbers¶
Pinning the versions of your dependencies in the requirements file
protects you from bugs or incompatibilities in newly released versions:
SomePackage == 1.2.3 DependencyOfSomePackage == 4.5.6
Using pip freeze to generate the requirements file will ensure that not
only the top-level dependencies are included but their sub-dependencies as
well, and so on. Perform the installation using —no-deps for an extra dose of insurance against installing
anything not explicitly listed.
This strategy is easy to implement and works across OSes and architectures.
However, it trusts PyPI and the certificate authority chain. It
also relies on indices and find-links locations not allowing
packages to change without a version increase. (PyPI does protect
against this.)
Hash-checking Mode¶
Beyond pinning version numbers, you can add hashes against which to verify
downloaded packages:
FooProject == 1.2 --hash=sha256:2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
This protects against a compromise of PyPI or the HTTPS
certificate chain. It also guards against a package changing
without its version number changing (on indexes that allow this).
This approach is a good fit for automated server deployments.
Hash-checking mode is a labor-saving alternative to running a private index
server containing approved packages: it removes the need to upload packages,
maintain ACLs, and keep an audit trail (which a VCS gives you on the
requirements file for free). It can also substitute for a vendor library,
providing easier upgrades and less VCS noise. It does not, of course,
provide the availability benefits of a private index or a vendor library.
For more, see pip install’s discussion of hash-checking mode.
Installation Bundles¶
Using pip wheel, you can bundle up all of a project’s dependencies, with
any compilation done, into a single archive. This allows installation when
index servers are unavailable and avoids time-consuming recompilation. Create
an archive like this:
$ tempdir=$(mktemp -d /tmp/wheelhouse-XXXXX) $ pip wheel -r requirements.txt --wheel-dir=$tempdir $ cwd=`pwd` $ (cd "$tempdir"; tar -cjvf "$cwd/bundled.tar.bz2" *)
You can then install from the archive like this:
$ tempdir=$(mktemp -d /tmp/wheelhouse-XXXXX) $ (cd $tempdir; tar -xvf /path/to/bundled.tar.bz2) $ pip install --force-reinstall --ignore-installed --upgrade --no-index --no-deps $tempdir/*
Note that compiled packages are typically OS- and architecture-specific, so
these archives are not necessarily portable across machines.
Hash-checking mode can be used along with this method to ensure that future
archives are built with identical packages.
Warning
Finally, 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 protections. If you need
to use such a package, see Controlling
setup_requires.