3 ms·
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 isola
by venantius 13y ago
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.
- kevcampb 13y agoI'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.
- steveklabnik 13y ago> Just saying "use full-isolation" doesn't solve the problem where I want to deploy multiple projects in the same unix environment. Isn't that not full isolation, then?
- lmm 13y agoYeah. 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.
- dissent 13y agoProvided 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.