You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/cookbook.rst
+47-26Lines changed: 47 additions & 26 deletions
Original file line number
Diff line number
Diff line change
@@ -7,41 +7,59 @@ Cookbook
7
7
Requirements Files
8
8
******************
9
9
10
-
A key idea in pip is that package versions listed in requirement files (or as :ref:`pip install` arguments),
11
-
have precedence over those that are located during the normal dependency resolution process that uses "install_requires" metadata.
10
+
"Requirements files" are files containing a list of items to be
11
+
installed using :ref:`pip install -r <install_--requirement>` like so:
12
12
13
-
This allows users to be in control of specifying an environment of packages that are known to work together.
13
+
::
14
14
15
-
Instead of running something like ``pip install MyApp`` and getting whatever libraries come along,
16
-
you'd run ``pip install -r requirements.txt`` where "requirements.txt" contains something like::
15
+
pip install -r requirements.txt
17
16
18
-
MyApp
19
-
Framework==0.9.4
20
-
Library>=0.2
21
17
22
-
Regardless of what MyApp lists in ``setup.py``, you'll get a specific version
23
-
of Framework (0.9.4) and at least the 0.2 version of
24
-
Library. Additionally, you can add optional libraries and support tools that MyApp doesn't strictly
25
-
require, giving people a set of recommended libraries.
18
+
Details on the format of the files are here: :ref:`Requirements File Format`.
26
19
27
-
Requirement files are intended to exhaust an environment and to be *flat*.
28
-
Maybe ``MyApp`` requires ``Framework``, and ``Framework`` requires ``Library``.
29
-
It is encouraged to still list all these in a single requirement file.
30
-
It is the nature of Python programs that there are implicit bindings *directly*
31
-
between MyApp and Library. For instance, Framework might expose one
32
-
of Library's objects, and so if Library is updated it might directly
33
-
break MyApp. If that happens you can update the requirements file to
34
-
force an earlier version of Library, and you can do that without
35
-
having to re-release MyApp at all.
36
20
37
-
To create a new requirements file from a known working environment, use::
21
+
There are 3 common use cases for requirements files:
38
22
39
-
$ pip freeze > stable-req.txt
23
+
1. When installing many things, it's easier to use a requirements file,
24
+
than specifying them all on the command line.
40
25
41
-
This will write a listing of *all* installed libraries to ``stable-req.txt``
42
-
with exact versions for every library.
26
+
2. Requirements files are often used to hold the result from :ref:`pip freeze`
27
+
for the purpose of achieving :ref:`repeatable installations <Repeatability>`.
28
+
In this case, your requirement file contains a pinned version of everything
29
+
that was installed when `pip freeze` was run.
43
30
44
-
For more information, see:
31
+
::
32
+
33
+
pip freeze > requirements.txt
34
+
pip install -r requirements.txt
35
+
36
+
3. Requirements files can be used to force pip to properly resolve dependencies.
37
+
As it is now, pip `doesn't have true dependency resolution
38
+
<https://github.com/pypa/pip/issues/988>`_, but instead simply uses the first
39
+
specification it finds for a project. E.g if `pkg1` requires `pkg3>=1.0` and
40
+
`pkg2` requires `pkg3>=1.0,<=2.0`, and if `pkg1` is resolved first, pip will
41
+
only use `pkg3>=1.0`, and could easily end up installing a version of `pkg3`
42
+
that conflicts with the needs of `pkg2`. To solve this problem, you can
43
+
place `pkg3>=1.0,<=2.0` (i.e. the correct specification) into your
44
+
requirements file directly along with the other top level requirements. Like
45
+
so:
46
+
47
+
::
48
+
49
+
pkg1
50
+
pkg2
51
+
pkg3>=1.0,<=2.0
52
+
53
+
54
+
It's important to be clear that pip determines package dependencies using `install_requires metadata
55
+
<http://pythonhosted.org/setuptools/setuptools.html#declaring-dependencies>`_, not by discovering `requirements.txt`
56
+
files embedded in projects.
57
+
58
+
For a good discussion on the conceptual differences between setup.py and
59
+
requirements, see `"setup.py vs requirements.txt" (an article by Donald Stufft)
60
+
<https://caremad.io/blog/setup-vs-requirement/>`_
61
+
62
+
See also:
45
63
46
64
* :ref:`Requirements File Format`
47
65
* :ref:`pip freeze`
@@ -215,6 +233,8 @@ If you would like to perform a non-recursive upgrade perform these 2 steps::
215
233
The first line will upgrade `SomePackage`, but not dependencies like `AnotherPackage`. The 2nd line will fill in new dependencies like `OneMorePackage`.
216
234
217
235
236
+
.. _`Repeatability`:
237
+
218
238
Ensuring Repeatability
219
239
**********************
220
240
@@ -361,3 +381,4 @@ setuptools>=0.7) by themselves cannot prevent this kind of problem.
0 commit comments