Add setup_requires caveat to repeatability section.

This commit is contained in:
Mark Kohler 2015-04-22 16:00:14 -07:00
parent 83815df61e
commit ee0f460f02
2 changed files with 6 additions and 2 deletions

View File

@ -453,6 +453,7 @@ the project path. This is one advantage over just using ``setup.py develop``,
which creates the "egg-info" directly relative the current working directory. which creates the "egg-info" directly relative the current working directory.
.. _`controlling-setup-requires`:
Controlling setup_requires Controlling setup_requires
++++++++++++++++++++++++++ ++++++++++++++++++++++++++

View File

@ -535,7 +535,7 @@ From within a real python, where ``SomePackage`` *is* installed globally, and is
Ensuring Repeatability Ensuring Repeatability
********************** **********************
Three things are required to fully guarantee a repeatable installation using requirements files. Four things are required to fully guarantee a repeatable installation using requirements files.
1. The requirements file was generated by ``pip freeze`` or you're sure it only 1. The requirements file was generated by ``pip freeze`` or you're sure it only
contains requirements that specify a specific version. contains requirements that specify a specific version.
@ -544,7 +544,10 @@ Three things are required to fully guarantee a repeatable installation using req
This guarantees that only what is explicitly listed in the requirements file is This guarantees that only what is explicitly listed in the requirements file is
installed. installed.
3. The installation is performed against an index or find-links location that is 3. None of the packages to be installed utilize the setup_requires keyword. See
:ref:`Controlling setup_requires<controlling-setup-requires>`.
4. The installation is performed against an index or find-links location that is
guaranteed to *not* allow archives to be changed and updated without a guaranteed to *not* allow archives to be changed and updated without a
version increase. Unfortunately, this is *not* true on PyPI. It is possible version increase. Unfortunately, this is *not* true on PyPI. It is possible
for the same pypi distribution to have a different hash over time. Project for the same pypi distribution to have a different hash over time. Project