Use single or double quotes around specifiers when using them in a shell to avoid > and < being
interpreted as shell redirects. e.g. pipinstall'FooProject>=1.2'.
Don’t use single or double quotes in a requirements.txt file.

Starting with v1.4, pip will only install stable versions as specified by
PEP426 by default. If a version cannot be parsed as a compliant PEP426
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 pipinstall command also supports a –pre flag
that will enable installing pre-releases and development releases.

Starting with v1.4, pip will warn about installing any file that does not come
from the primary index. As of version 1.5, pip defaults to ignoring these files
unless asked to consider them.

The pipinstall command supports a
–allow-external PROJECT option that will enable
installing links that are linked directly from the simple index but to an
external host that also have a supported hash fragment. Externally hosted
files for all projects may be enabled using the
–allow-all-external flag to the pipinstall
command.

The pipinstall command also supports a
–allow-unverified PROJECT option that will enable
installing insecurely linked files. These are either directly linked (as above)
files without a hash, or files that are linked from either the home page or the
download url of a package.

These options can be used in a requirements file. Assuming some fictional
ExternalPackage that is hosted external and unverified, then your requirements
file would be like so:

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.

The “project name” component of the url suffix “egg=<project name>-<version>”
is used by pip in its dependency logic to identify the project prior
to pip downloading and analyzing the metadata. The optional “version”
component of the egg name is not functionally important. It merely
provides a human-readable clue as to what version is in use.

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 it’s 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.

When storing items in the cache pip will respect the CacheControl header
if it exists, or it will fall back to the Expires header if that exists.
This allows pip to function as a browser would, and allows the index server
to communicate to pip how long it is reasonable to cache any particular item.

While this cache attempts to minimize network activity, it does not prevent
network access all together. If you want a fast/local install solution that
circumvents accessing PyPI, see Fast & Local Installs.

The default location for the cache directory depends on the Operating System:

(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.pydevelop,
which creates the “egg-info” directly relative the current working directory.

Setuptools offers the setup_requiressetup() 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.

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.

Install packages as eggs, not ‘flat’, like pip normally does. This option is not about installing from eggs. (WARNING: Because this option overrides pip’s normal install logic, requirements files may not behave as expected.)