When a venv already exists, and a projects dependencies change, tox fails to detect that, which leads to ez-install running - and thats both slower as well as liable to break because of the differences between ez-install and pip.
The underlying issue is this if test:https://bitbucket.org/hpk42/tox/src/4dbfb1f1eb86b35cbd2c83461e1e294651e89cf6/tox/venv.py?at=default&fileviewer=file-view-default#venv.py-226
For a new venv, the sdist (or develop equivalently) is installed with no special parameters, which leaves it up to pip to ensure its installed properly.
On subsequent tox invocations however, -U --no-deps is passed. This has two separate, interacting effects: - things installed by other commands (e.g. the installdeps commands) are inappropriately upgraded. pip does not remember that e.g. foo<5 was passed, only that foo is installed, and if foo is in the transitive dependency set of the packages dependencies, -U will cause it to be upgraded. This matters in that it can invalidate lower-bounds testing by causing deliberately-set-low versions to be upgraded.
- new dependencies of the package are not installed at all if the recreation-on-changes- is not detected - this happens build systems that have metadata outside of setup.py, so that the automatic recreation is not triggered. e.g. d2to1, pbr, ... They may get installed via easy-install, so its not obvious to users that this is happening, but it certainly does.
I'm not entirely sure of the history of adding these options, but since pip only installs things that are missing or incompatible, there is really no reason for them to be passed at all: just always installing as-is should be both fast and correct IMO.
Separately we should look at teaching tox to more reliably detect when to recreate the venv, but as noted - this current behaviour is incorrect even when the package dependencies haven' changed.