On 03/23/2012 09:22 PM, PJ Eby wrote:

On Mar 23, 2012 3:53 PM, "Carl Meyer"

...

On 03/23/2012 12:35 PM, PJ Eby wrote:

...

AFAICT, virtualenvs are overkill for most development anyway. If you're not using distutils except to install dependencies, then configure distutils to install scripts and libraries to the same directory, and then do all your development in that directory. Presto! You now have a cross-platform "virtualenv". Want the scripts on your path? Add that directory to your path... or if on Windows, don't bother, since the current directory is usually on the path. (In fact, if you're only using easy_install to install your dependencies, you don't even need to edit the distutils configuration, just use "-md targetdir".)

Creating and using a virtualenv is, in practice, _easier_ than any of those alternatives,

Really? As I said, I've never seen the need to try, since just installing stuff to a directory on PYTHONPATH seems quite easy enough for me.

...

that the "isolation from system site-packages" feature is quite popular (the outpouring of gratitude when virtualenv went isolated-by-default a few months ago was astonishing), and AFAIK none of your alternative proposals support that at all.

What is this isolation for, exactly? If you don't want site-packages on your path, why not use python -S?

(Sure, nobody knows about these things, but surely that's a documentation problem, not a tooling problem.)

Don't get me wrong, I don't have any deep objection to virtualenvs, I've just never seen the *point* (outside of the scenarios I mentioned),

No problem. I was just responding to the assertion that people only use virtualenvs because they aren't aware of the alternatives, which I don't believe is true. It's likely many people aren't aware of python -S, or of everything that's possible via distutils.cfg. But even if they were, for the cases where I commonly see virtualenv in use, it solves the same problems more easily and with much less fiddling with config files and environment variables. Case in point: libraries that also install scripts for use in development or build processes. If you're DIY, you have to figure out where to put these, too, and make sure it's on your PATH. And if you want isolation, not only do you have to remember to run python -S every time, you also have to edit every script wrapper to put -S in the shebang line. With virtualenv+easy_install/pip, all of these things Just Simply Work, and (mostly) in an intuitive way. That's why people use it.

thus don't see what great advantage will be had by rearranging layouts to make them shareable across platforms, when "throw stuff in a directory" seems perfectly serviceable for that use case already. Tools that *don't* support "just throw it in a directory" as a deployment option are IMO unpythonic -- practicality beats purity, after all. ;-)

No disagreement here. I think virtualenv's sweet spot is as a convenient tool for development environments (used in virtualenvwrapper fashion, where the file structure of the virtualenv itself is hidden away and you never see it at all). I think it's fine to deploy _into_ a virtualenv, if you find that convenient too (though I think there are real advantages to deploying just a big ball of code with no need for installers). But I see little reason to make virtualenvs relocatable or sharable across platforms. I don't think virtualenvs as on on-disk file structure make a good distribution/deployment mechanism at all. IOW, I hijacked this thread (sorry) to respond to a specific denigration of the value of virtualenv that I disagree with. I don't care about making virtualenvs consistent across platforms. Carl