A lot of this seems to boil down to a combination of seeing others misuse tools and assuming that's what they're for (which is a communication/teaching failure, not a failure of the tool), and looking at stepping-stone solutions.
Take binary packages, for example. Sure, eggs did that. Sort of. But they also introduced a weird parallel universe where you had to stop doing normal Python things and start doing egg things. So pip eschewed eggs.
And meanwhile the community banded together to find a way to separate the build and install processes, the result of which is the wheel format:
Similarly, virtual environments are still being improved (with the improvements now being integrated direct into Python itself).
And yes, you can use pip's requirements files as a duplicate way to specify dependencies. And people do that, and it's unfortunate. Because the thing requirements files are really useful for is specifying a particular environment that you want to replicate. That might be a known-good set of stuff you've tested and now want to deploy on, it might be an experimental combination of things you want others to test, etc., but that's something setup.py's dependency system isn't good at. And repeatable/replicable environments are certainly an important thing.
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.
i was pleased to see wheel mentioned. here is a wheel anecdote:
suppose you wanted to automate the installation of a python package to a windows machine, but the package has binary dependencies, is irritating to build from source, and is distributed as a pre-built .exe interactive installer (click next, next, ...). you can `wheel convert` the exe installer to get a binary wheel archive, then automate the installation of that wheel archive with pip. hopefully this isn't a common scenario, but the fact that pip + wheel make this kind of thing possible at all is very helpful.
I fail to see the attraction of wheel, and the uptake since it was invented appears to be basically non-existent.
Can someone seriously explain what the point of it is?
As far as I can tell, it's: make life easier for windows python users (which I am one of, and I don't care about it at all; you need VS to build everything anyway; one or two wheel modules makes zero difference; it'll only make a difference when everything uses wheel, which will be never...).
I read the wheel PEP. I got to the part about munging #! shebang lines and stopped reading. Shebang is just totally irrelevant outside of interactive command line convenience. Just run the python you want to run explicitly! Just like java.
Take binary packages, for example. Sure, eggs did that. Sort of. But they also introduced a weird parallel universe where you had to stop doing normal Python things and start doing egg things. So pip eschewed eggs.
And meanwhile the community banded together to find a way to separate the build and install processes, the result of which is the wheel format:
http://www.python.org/dev/peps/pep-0427/
Similarly, virtual environments are still being improved (with the improvements now being integrated direct into Python itself).
And yes, you can use pip's requirements files as a duplicate way to specify dependencies. And people do that, and it's unfortunate. Because the thing requirements files are really useful for is specifying a particular environment that you want to replicate. That might be a known-good set of stuff you've tested and now want to deploy on, it might be an experimental combination of things you want others to test, etc., but that's something setup.py's dependency system isn't good at. And repeatable/replicable environments are certainly an important thing.
etc., etc.