[00:36:35] <twm> pixelfog: virtualenvs are not portable, so system upgrades can break an app packaged with dh_virtualenv if the system's Python shared library becomes incompatible with the python binary in the virtualenv.
[00:41:11] <carljm> Of course, that objection applies to virtualenv in general, not dh_virtualenv specifically.
[00:41:55] <twm> Well with dh_virtualenv the goal is to be able to distribute the resulting .deb, so you could argue it's broken by design. ;)
[00:42:42] <twm> I don't frequently tar up my development virtualenvs and move them to another machine; I just recreate them with tox.
[00:43:51] <carljm> twm: Yes, if dh_virtualenv involves tarring up an entire virtualenv for deployment elsewhere, you'd need to be careful to only install the resulting deb on the same architecture/python-version/library-versions etc
[00:44:00] <carljm> That's usually not a good idea.
[00:44:20] <carljm> But it's also true that _any_ virtualenv can become broken if the underlying base Python is upgraded in place.
[01:04:16] <twm> Yeah, I just wouldn't say that limitation makes virtualenv broken and dangerous in the same way dh_virtualenv is.
[02:00:54] <_habnabit> pixelfog, the implementation is bad, mostly
[02:01:04] <_habnabit> pixelfog, i can't remember; last time i used it i had to patch it
[17:25:10] <jessamyn_> oh bash scripting, where I just try random things
[20:24:48] <skylite> is it possible to change the ~/.cache/pip/log default location to the virtualenvs location, if I use pip in a virtualenv?
[21:16:55] <jessamyn_> skylite: hm... not entirely sure why you'd want separate caches, but...