Yeah, I think that was largely my reaction as well. Attacking virtualenv in particular because you've seen others use it as a replacement for a completely isolated environment just says that at the very least they didn't understand its intended use case, and perhaps OP doesn't either.
Also, while I support his offering a full-isolation alternative, realistically not everybody is going to want to develop in a Vagrant environment. It's a great solution if you're willing to run with that sort of overhead, but not everybody is.
I'm not sure that full-isolation is an alternative, they're somewhat orthogonal solutions. It's perfectly normal to use pip and virtualenv inside a virtual container, so that the base operating system is a known environment.
Just saying "use full-isolation" doesn't solve the problem where I want to deploy multiple projects in the same unix environment. Heaven forbid I might want two processes from different projects to cooperate, without needing to do everything via APIs and TCP. Overheads there are not just performance, but also development time.
Yeah. pip/virtualenv allows you to run multiple python processes without full isolation, but without conflicting with each other's libraries either. That's the point.
Provided there's no conflict outside of python, that is. This is also sounds like a deployment scenario, in which case it ought to be non-interactive, in which case you can set sys.path in your entry point. That's the point.
Also, while I support his offering a full-isolation alternative, realistically not everybody is going to want to develop in a Vagrant environment. It's a great solution if you're willing to run with that sort of overhead, but not everybody is.