Requirements File Format - pip documentation v25.2.dev0 (original) (raw)
Toggle table of contents sidebar
Requirements files serve as a list of items to be installed by pip, when using pip install. Files that use this format are often called “pip requirements.txt files”, since requirements.txt is usually what these files are named (although, that is not a requirement).
Note
The requirements file format is closely tied to a number of internal details of pip (e.g., pip’s command line options). The basic format is relatively stable and portable but the full syntax, as described here, is only intended for consumption by pip, and other tools should take that into account before using it for their own purposes.
Example¶
This is a comment, to show how #-prefixed lines are ignored.
It is possible to specify requirements as plain names.
pytest pytest-cov beautifulsoup4
The syntax supported here is the same as that of requirement specifiers.
docopt == 0.6.1 requests [security] >= 2.8.1, == 2.8.* ; python_version < "2.7" urllib3 @ https://github.com/urllib3/urllib3/archive/refs/tags/1.26.8.zip
It is possible to refer to other requirement files or constraints files.
-r other-requirements.txt -c constraints.txt
It is possible to refer to specific local distribution paths.
./downloads/numpy-1.9.2-cp34-none-win32.whl
It is possible to refer to URLs.
Structure¶
Each line of the requirements file indicates something to be installed, or arguments to pip install. The following forms are supported:
[[--option]...]<requirement specifier><archive url/path>[-e] <local project path>[-e] <vcs project url>
For details on requirement specifiers, see Requirement Specifiers. For examples of all these forms, see Examples.
Encoding¶
The default encoding for requirement files is UTF-8 unless a different encoding is specified using a PEP 263 style comment (e.g. # -*- coding: <encoding name> -*-).
Line continuations¶
A line ending in an unescaped \ is treated as a line continuation and the newline following it is effectively ignored.
Supported options¶
Requirements files only supports certain pip install options, which are listed below.
Global options¶
The following options have an effect on the entire pip install run, and must be specified on their individual lines.
- -i, --index-url
- --extra-index-url
- --no-index
- -c, --constraint
- -r, --requirement
- -e, --editable
- -f, --find-links
- --no-binary
- --only-binary
- --prefer-binary
- --require-hashes
- --pre
- --trusted-host
- --use-feature
Example
To specify --pre, --no-indexand two --find-links locations:
--pre --no-index --find-links /my/local/archives --find-links http://some.archives.com/archives
Per-requirement options¶
Added in version 7.0.
The options which can be applied to individual requirements are:
- --global-option
- --config-settings
--hash(for Hash-checking Mode)
Referring to other requirements files¶
If you wish, you can refer to other requirements files, like this:
You can also refer to constraints files, like this:
Using environment variables¶
Added in version 10.0.
pip supports the use of environment variables inside the requirements file.
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 $VARIABLEand %VARIABLE%.
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 used12-factor configuration pattern.
Influencing the build system¶
Danger
This disables the use of wheels (cached or otherwise). This could mean that builds will be slower, less deterministic, less reliable and may not behave correctly upon installation.
This mechanism is only preserved for backwards compatibility and should be considered deprecated. A future release of pip may drop these options.
The --global-option option is used to pass options to setup.py.
Attention
These options are highly coupled with how pip invokes setuptools using the setup.py (legacy) build system interface. It is not compatible with newer pyproject.toml build system interface.
This is will not work with other build-backends or newer setup.cfg-only projects.
If you have a declaration like:
FooProject >= 1.2 --global-option="--no-user-cfg"
The above translates roughly into running FooProject’s setup.py script as:
python setup.py --no-user-cfg install
Note that the only way of giving more than one option to setup.py is through multiple --global-option options.