3 ms·
Can someone explain the historical reasons for this problem even existing in the first place? (the problem that virtual env solves)
by mkoryak 14y ago
Can someone explain the historical reasons for this problem even existing in the first place? (the problem that virtual env solves)
- HeyImAlex 14y agoDid... did you read the article? Separation of environments for projects with different dependencies.
- mkoryak 14y agojava does not have virtual envs, and i can have projects with different dependancies. clearly this is a python problem. I was asking why it exists.
- metaphorm 14y agothe problem is that different applications might require different versions of the same packages. if you install packages globally then you can only ever have one version available. this is a VERY BAD THING if you have any expectation of running more than application per machine.
- jamesjporter 14y agoIt also comes in handy when I'm trying to install something finicky that has a million dependencies, each of which also might be finicky (e.g. numba) and I screw something up and just want to start over clean and not muck around uninstalling things. virtualenv makes this easy—I just make a new environment for experimenting and then delete it if I mess up and want to start over, leaving my system configuration clean and other environments intact.
- randuser 14y agosetuptools/distribute didn't implement `python setup.py uninstall`. Unix fragmentation of where the bin and lib directories should reside, i.e. /bin, /usr/bin, /usr/local/bin, ~/bin, ... Windows doesn't have symlinks and the different packaging tools have tried to implement the functionality in various different ways. Python doesn't add the path of the "main" executed file to the module lookup path. (edit: actually, I think this is wrong. I meant to say "Python module import lookup is complicated.")