- check build requirements for conflicts
- better isolation (ignore system site packages)
- support 2 prefixes: a "normal" one, and an "overlay" one
(with higher priority over "normal")
Add a new testsuite option `--use-venv` to enable the use of `venv`
for creating a test virtual environment. The option is opt-in because
creating a `venv` environment does not work right when running under a
`virtualenv`; which is why `tox-venv` must be used in combination with
tox.
- cleanup virtualenv creation code
- ensure all testing virtual environments use a recent version
of setuptools / wheel, making it easier to switch to custom
versions of those, as well as reducing network accesses
- reduce size of testing virtual environment, slightly speeding
up the testsuite
Offload more work to the underlying pip command used to install the
build requirements, so there's no need to duplicate code to handle
environment markers/extras. This is done by setting the correct options
from the finder passed in argument to `_install_build_reqs`.
Speedup virtualenv creation: create one (per session) relocatable
virtual environment, and then just make a copy of the resulting tree
when a new virtualenv is needed.
* 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.
`pip download` has the same functionality as `pip install --download`,
and the behavior of `pip install --download` is preserved with a deprecation
warning. `pip install --download` will be removed in pip version 10.
Instead of:
tests/conftest.py:146: in virtualenv
pip_source_dir=pip_src,
tests/lib/venv.py:45: in create
obj._create(clear=clear)
tests/lib/venv.py:68: in _create
raise Exception(p.stderr)
E Exception: None
We get the more informative:
tests/conftest.py:146: in virtualenv
pip_source_dir=pip_src,
tests/lib/venv.py:45: in create
obj._create(clear=clear)
tests/lib/venv.py:71: in _create
output=p.stdout,
E CalledProcessError: Command '[Path(u'/private/var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/pytest-675/test_freeze_basic0/workspace/venv/bin/python'), 'setup.py', 'installxx']' returned non-zero exit status 1
because `path_to_url` is smarter than the ad-hoc code I hacked together.
In particular, it works on Windows, whereas my code didn't. This
prevents the following error on Windows:
Script result: svn import c:\users\admini~1\appdata\local\temp\pytest-27\test_freeze_svn0\workspace\scratch\version_pkg file://c:\users\admini~1\appdata\local\temp\pytest-27\test_freeze_svn0\workspace\scratch\pip-test-package-repo\trunk -m Initial import of pip-test-package
return code: 1
-- stderr: --------------------
svn: E170000: Illegal repository URL 'file://c:%5cusers%5cadmini~1%5cappdata%5clocal%5ctemp%5cpytest-27%5ctest_freeze_svn0%5cworkspace%5cscratch%5cpip-test-package-repo%5ctrunk'
using object that have the same name as submodules as the weird effect
of makeing `import pip.commands.<something> as <anothername>` fail with
a key error. This fixes it by renamin commands as command_dict and fixin
a few imports to accomodate.
Related to #2149
Conflicts:
CHANGES.txt
tests/functional/test_install_reqs.py
tests/lib/__init__.py
tests/unit/test_req.py
Additional work - refactored tests to new style.
Previously pip was always installed directly from the source tree
however this causes concurrency issues so it is now copied into
the temporary directory and installed from there.
This is needed because the various activities that exericsing the
tests do will cause files to change inside this data directory. If
we do not make it test specific then we run into concurrency issues.
* Move virtualenv creation out of TestPipEnvironment
* Remove global state and force explicit use of TestPipEnvironment
instances
* Remove "backup" virtualenv copying and instead create new
virtual environments each time.
* Remove the monkeypatched "PyPICache" functionality
* Remove things that were not being used anymore and were dead
weight
* Remove sitecustomize support which was primarily used to
monkeypatch the "PyPICache" but was used in one or two other
tests.
* Add a .join() method for a more explicit joining than /
* Return values where possible
* Make glob an iterator
* Remove checks for versions of Python we don't support
* Add a write() function to make it simple to write some text
into a file
* Add a touch() function to make it simple to ensure a file
exists
* Better output with the bare asserts we use throughout the tests
* Function fixtures are pretty nice, especially as a way to
start a background server or create an isolated virtualenv
