![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
On Sun, Jan 3, 2010 at 17:42, Nathaniel Smith <njs@pobox.com> wrote:
On Sun, Jan 3, 2010 at 4:23 AM, David Cournapeau <cournape@gmail.com> wrote:
On Sun, Jan 3, 2010 at 8:05 PM, Nathaniel Smith <njs@pobox.com> wrote:
What I do -- and documented for people in my lab to do -- is set up one virtualenv in my user account, and use it as my default python. (I 'activate' it from my login scripts.) The advantage of this is that easy_install (or pip) just works, without any hassle about permissions etc.
It just works if you happen to be able to build everything from sources. That alone means you ignore the majority of users I intend to target.
No other community (except maybe Ruby) push those isolated install solutions as a general deployment solutions. If it were such a great idea, other people would have picked up those solutions.
AFAICT, R works more-or-less identically (once I convinced it to use a per-user library directory); install.packages() builds from source, and doesn't automatically pull in and build random C library dependencies.
That's not quite the same. That is the R equivalent of Python's recent per-user site-packages feature (every user get's their own sandbox), not virtualenv (every project gets it's own sandbox). The former feature has a long history in the multiuser UNIX world and is not really controversial. http://www.python.org/dev/peps/pep-0370/ -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco