The requests one does currently sit at 10KB, the io buffer one at 8KB.
Both are reasonable values and slightly above our current values.
If those values are adjusted, we will profit as well.
* 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.
6.1.1 and before use git clones when installing a git+ url. 7.0.0.dev
didn't temporarily because the internal flag for controlling whether
to do a clone or an export was tied into the behaviour for whether
something will be deleted or not - which is arguably different. Remove
the confounded behaviour and just unpack always, using the same marker
flag to delete directories as used for file and non-vcs urls.
E.g.: `pip install /path/to/dir`
by building an sdist and then unpacking it instead of doing
`shutil.copytree`. `shutil.copytree` may copy files that aren't included
in the sdist, which means that:
1. If those files are large, a `pip install` could take much longer than
it should.
2. Folks that are using `python setup.py install` to test their package
are not fully testing it, because it may copy over files that wouldn't
be there if they built and sdist and installed that.
So this method building an sdist is both more accurate and faster.
Fixes https://github.com/pypa/pip/issues/2195
In _download_url pip was checking the download hash in a finally block
so that it was always checked regardless of download success. This is
problematic when downloads fail in a way that will make the hash check
fail. For example, downloading zero bytes so that a zero byte file is
hashed. When this happens the hash mismatch is reported to the user and
not the underlying network issue that was run into.
Fix this by removing the try finally block completely so that early
errors are bubbled up and reported to users.
Fix issue 2332
