@@ -197,18 +197,16 @@ In practice, there are 4 common uses of Requirements files:
197
197
py -m pip freeze > requirements.txt
198
198
py -m pip install -r requirements.txt
199
199
200
- 2. Requirements files are used to force pip to properly resolve
201
- dependencies. In versions of pip prior to 20.3, pip `doesn't have
202
- true dependency resolution
203
- <https://github.com/pypa/pip/issues/988> `_, but instead simply uses
204
- the first specification it finds for a project. E.g. if ``pkg1 ``
205
- requires ``pkg3>=1.0 `` and ``pkg2 `` requires ``pkg3>=1.0,<=2.0 ``,
206
- and if ``pkg1 `` is resolved first, pip will only use ``pkg3>=1.0 ``,
207
- and could easily end up installing a version of ``pkg3 `` that
208
- conflicts with the needs of ``pkg2 ``. To solve this problem for
209
- pip 20.2 and previous, you can place ``pkg3>=1.0,<=2.0 `` (i.e. the
210
- correct specification) into your requirements file directly along
211
- with the other top level requirements. Like so::
200
+ 2. Requirements files are used to force pip to properly resolve dependencies.
201
+ pip 20.2 and earlier `doesn't have true dependency resolution
202
+ <https://github.com/pypa/pip/issues/988> `_, but instead simply uses the first
203
+ specification it finds for a project. E.g. if ``pkg1 `` requires
204
+ ``pkg3>=1.0 `` and ``pkg2 `` requires ``pkg3>=1.0,<=2.0 ``, and if ``pkg1 `` is
205
+ resolved first, pip will only use ``pkg3>=1.0 ``, and could easily end up
206
+ installing a version of ``pkg3 `` that conflicts with the needs of ``pkg2 ``.
207
+ To solve this problem, you can place ``pkg3>=1.0,<=2.0 `` (i.e. the correct
208
+ specification) into your requirements file directly along with the other top
209
+ level requirements. Like so::
212
210
213
211
pkg1
214
212
pkg2
@@ -291,7 +289,11 @@ organisation and use that everywhere. If the thing being installed requires
291
289
"helloworld" to be installed, your fixed version specified in your constraints
292
290
file will be used.
293
291
294
- Constraints file support was added in pip 7.1.
292
+ Constraints file support was added in pip 7.1. In :ref: `Resolver
293
+ changes 2020` we did a fairly comprehensive overhaul, removing several
294
+ undocumented and unsupported quirks from the previous implementation,
295
+ and stripped constraints files down to being purely a way to specify
296
+ global (version) limits for packages.
295
297
296
298
.. _`Installing from Wheels` :
297
299
@@ -1437,17 +1439,37 @@ time to fix the underlying problem in the packages, because pip will
1437
1439
be stricter from here on out.
1438
1440
1439
1441
This also means that, when you run a ``pip install `` command, pip only
1440
- considers the packages you are installing in that command, and may
1441
- break already-installed packages. It will not guarantee that your
1442
+ considers the packages you are installing in that command, and ** may
1443
+ break already-installed packages ** . It will not guarantee that your
1442
1444
environment will be consistent all the time. If you ``pip install x ``
1443
1445
and then ``pip install y ``, it's possible that the version of ``y ``
1444
1446
you get will be different than it would be if you had run ``pip
1445
- install x y `` in a single command. We would like your thoughts on what
1447
+ install x y `` in a single command. We are considering changing this
1448
+ behavior (per :issue: `7744 `) and would like your thoughts on what
1446
1449
pip's behavior should be; please answer `our survey on upgrades that
1447
1450
create conflicts `_.
1448
1451
1449
- We are also changing our support for :ref: `Constraints Files `:
1450
-
1452
+ We are also changing our support for :ref: `Constraints Files `,
1453
+ editable installs, and related functionality. We did a fairly
1454
+ comprehensive overhaul and stripped constraints files down to being
1455
+ purely a way to specify global (version) limits for packages, and so
1456
+ some combinations that used to be allowed will now cause
1457
+ errors. Specifically:
1458
+
1459
+ * Constraints don't override the existing requirements; they simply
1460
+ constrain what versions are visible as input to the resolver (see
1461
+ :issue: `9020 `)
1462
+ * Providing an editable requirement (``-e . ``) does not cause pip to
1463
+ ignore version specifiers or constraints (see :issue: `8076 `), and if
1464
+ you have a conflict between a pinned requirement and a local
1465
+ directory then pip will indicate that it cannot find a version
1466
+ satisfying both (see :issue: `8307 `)
1467
+ * Hash-checking mode requires that all requirements are specified as a
1468
+ ``== `` match on a version and may not work well in combination with
1469
+ constraints (see :issue: `9020 ` and :issue: `8792 `)
1470
+ * If necessary to satisfy constraints, pip will happily reinstall
1471
+ packages, upgrading or downgrading, without needing any additional
1472
+ command-line options (see :issue: `8115 ` and :doc: `development/architecture/upgrade-options `)
1451
1473
* Unnamed requirements are not allowed as constraints (see :issue: `6628 ` and :issue: `8210 `)
1452
1474
* Links are not allowed as constraints (see :issue: `8253 `)
1453
1475
* Constraints cannot have extras (see :issue: `6628 `)
0 commit comments