virtualenv is not recreated when deps change if '-r' is used

[pytoxbot]

• Bitbucket: https://bitbucket.org/hpk42/tox/issue/149
• Originally reported by: @gavrie
• Originally created at: 2014-01-28T15:36:07.365

In my tox.ini, I have the following deps:

deps = -rpackaging/requirements.txt

Normally, when deps change, the virtualenv is recreated by tox.
However, when the contents of requirements.txt change, tox does not notice this and the environment is reused.

A workaround would be to list the deps directly in tox.ini, but that would require duplicating the contents of the existing requirements.txt that is used by other tools.

[pytoxbot]

Original comment by wbyoung

@wmyll6 thanks for the plugin. Hopefully some of that work can make its way into the core!

[pytoxbot]

Original comment by @signalpillar

Hello guys, I've created an experimental project that supports venv recreation on requirements file update.
Maybe it will be useful for you in some way: https://github.com/signalpillar/tox-battery

Implemented using plugin system that was added recently to the tox.

[pytoxbot]

Original comment by hexadite-maxk

This is rather philosophical question: if we want tox to be smart or stupid.
IF we want it stupid - adding new smart features is out of the question.

[pytoxbot]

Original comment by @merwok

This also happens if dependencies in setup.py (install_requires) change.

[pytoxbot]

Original comment by @hpk42

Within tox-1.9.1 (superseded quickly by 1.9.2) we had some code that parsed requirement files but it was buggy and caused problems.

I am all for adding proper support for dealing with requirement files in deps.

I think that tox will need to support pip==1.5.6 at least if not older versions.

[pytoxbot]

Original comment by @hpk42

If somebody can submit a PR helping with working better with "-r" lines, please do. Note that i just released tox-1.9.1 which contains some code in relation to "--force-deps" which parses requirements.

[pytoxbot]

Original comment by @bukzor

That's only slightly better. Requirement files can and do contain '-r
more.txt' lines to pull in further requirements.

To the dependency concern: tox already has a hard dependency on virtualenv,
which contains a vendored copy of pip. We can make use of this if necessary.

--phone is hard.

[pytoxbot]

Original comment by mhirota

What about recognizing the special case of deps = -r<something> and calculating the md5 based on the file contents? This would trigger recreate if anything in the requirements.txt changed... but I think that might be better than duplicating what is in pip or introducing a hard dependency on pip in tox.

[pytoxbot]

Original comment by @hashar

A way to reproduce:

$ cat tox.ini
[tox]
skipsdist = True

[testenv:venv]
deps = -rrequirements.txt

$ echo -n > requirements.txt
$ tox
...
$ cat .tox/venv/.tox-config1 
00000000000000000000000000000000 /usr/local/opt/python/bin/python2.7
1.8.1 0 0 0
00000000000000000000000000000000 -rrequirements.txt
$

Then add a new requirement and rerun tox:

$ echo pep8 > requirements.txt
$ tox -vvv
$ tox -vvv
  removing /private/tmp/toxdeps/.tox/log
using tox.ini: /private/tmp/toxdeps/tox.ini
using tox-1.8.1 from /usr/local/lib/python2.7/site-packages/tox/__init__.pyc
skipping sdist step
venv start: getenv /private/tmp/toxdeps/.tox/Venn
venv reusing: /private/tmp/toxdeps/.tox/venv
     ^^^^^^^
venv finish: getenv after 0.02 seconds
venv start: finishvenv 
venv finish: finishvenv after 0.00 seconds
...

.tox-config1 remains identical.

VirtualEnv._getresolvedeps() should be made to understand the '-rsomefile.txt' and parse its content, or even better delegate the dependencies resolution to pip itself. pip.req.parse_requirements() has all the logic :-}

[pytoxbot]

Original comment by @asottile

For what it's worth, here's a hacky workaround with a Makefile: http://stackoverflow.com/questions/23032580/reinstall-virtualenv-with-tox-when-requirements-txt-or-setup-py-changes/23039826#23039826

[dimaqq]

Any chance of porting tox-battery here?

[RonnyPfannschmidt]

@dimaqq it already is on github - @signalpillar is the maintainer/owner