`pip install -r reqs.txt` was failing when the requirements file includes
an unsupported wheel, regardless of whether it is conditionally removed
by a marker. This patch fixes that issue.
Additionally, this patch makes pip check local file wheels for
compatibility. Previously, a requirements file could include a path
to a valid wheel for any platform and pip would happily install it.
Removed the mention of "package index options" in the docs, because they don't all fit that category anymore. Not even --no-binary and --only-binary do; they're "install options".
For dependencies that are properly pinned and hashed (not really dependencies at all, if you like, since they're explicit, root-level requirements), we install them as normal. For ones that are not pinned and hashes, we raise the errors typical of any unhashed requirement in --require-hashes mode.
Since the stanza under "if not ignore_dependencies" doesn't actually add anything if it's already in the RequirementSet, not much has to be done in the way of code: the unhashed deps don't have any hashes, so we complain about them as per usual.
Also...
* Revise wording of HashUnpinned errors. They can be raised even if no hash is specified, so the previous wording was misleading.
* Make wording of HashMissing less awkward.
dstufft is nervous about blowing a single-char option on something that will usually be copied and pasted anyway. We can always put it back later if it proves to be a pain.
* Add --require-hashes option. This is handy in deployment scripts to force application authors to hash their requirements. It is also a convenient way to get pip to show computed hashes for a virgin, unhashed requirements file. Eventually, additions to `pip freeze` should fill a superset of this use case.
* In --require-hashes mode, at least one hash is required to match for each requirement.
* Option-based requirements (--sha256=...) turn on --require-hashes mode implicitly.
* Internet-derived URL-based hashes are "necessary but not sufficient": they do not satisfy --require-hashes mode when they match, but they are still used to guard against transmission errors.
* Other URL-based requirements (#md5=...) are treated just like flag-based ones, except they don't turn on --require-hashes.
* Complain informatively, with the most devastating errors first so you don't chase your tail all day only to run up against a brick wall at the end. This also means we don't complain that a hash is missing, only for the user to find, after fixing it, that we have no idea how to even compute a hash for that type of requirement.
* Complain about unpinned requirements when hash-checking mode is on, lest they cause the user surprise later.
* Complain about missing hashes.
* Complain about requirement types we don't know how to hash (like VCS ones and local dirs).
* Have InstallRequirement keep its original Link around (original_link) so we can differentiate between URL hashes from requirements files and ones downloaded from the (untrustworthy) internet.
* Remove test_download_hashes, which is obsolete. Similar coverage is provided in test_utils.TestHashes and the various hash cases in test_req.py.
This allows lines such as the following to exist in requirements files:
INITools==0.2 --install-options="--prefix=/opt"
virtualenv>=1 --global-options="--no-user-cfg"
In addition, the requirements file parser was overhauled with simplicity
and clarity in mind.
This speeds up the _filter_install function that is used to filter the
output of `python setup.py install` when installing packages. It does
this by using a single regex which is pre-compiled and thus avoiding a
`for` loop over 15 different regexes.
Before:
$ python
Python 2.7.9 (v2.7.9:648dcafa7e5f, Dec 10 2014, 10:10:46)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> timeit.timeit("""_filter_install("if we've already set distribute as a conflict to setuptools blah blah blah blah")""", setup='from pip.req.req_install import InstallRequirement; ir = InstallRequirement("foo", None, None); _filter_install = ir._filter_install')
21.220640897750854
After:
$ python
Python 2.7.9 (v2.7.9:648dcafa7e5f, Dec 10 2014, 10:10:46)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> timeit.timeit("""_filter_install("if we've already set distribute as a conflict to setuptools blah blah blah blah")""", setup='from pip.req.req_install import InstallRequirement; ir = InstallRequirement("foo", None, None); _filter_install = ir._filter_install')
0.9454500675201416
If an exact version is specified for install, and that version is
already installed, then there is no point going to pypi as no install
is needed.
Adds a test called
`test_upgrade_no_look_at_pypi_if_exact_version_installed`.
This is a rework of PR #771, because that PR is old and has merge
conflicts that were easier to fix by applying the changes manually.
Without this, I was getting:
$ pip install -U 'sentry[lol]'
...
UnknownExtra: Unknown 7.4.1 has no such extra feature 'lol'
With this, I get:
$ pip install -U 'sentry[lol]'
...
UnknownExtra: sentry 7.4.1 has no such extra feature 'lol'
use pkg_resources.Distribution.requires instead of
Requirements.requirements to have environment markers parsing for free
It also unifies a little the process for wheel and non-wheel installs
closes#2174
