7 ms·
Virtualenv to be part of Python 3.3
- famousactress 14y agoAwesome! I'm hard pressed to think of a third party tool that makes more sense for core-inclusion than virtualenv. Hoping the virtualenvwrapper stuff will also be included (or at least similar commands will be)
- lloeki 14y agoI'm personally not fond of the virtualenvwrapper porcelain: cd foo; workon foo is an extremely marginal improvement over sourcing the activate file, especially when routinely opening and closing terminal tabs and windows. I use a number of zsh functions and hooks as porcelain to virtualenv so that it behaves like oh-my-zsh bundler support [0] (which I've shamelessly ripped of and tweaked too) i.e being inside foo directory is sufficient. This works especially well since new tabs open straight into the current tab's wd. [0] https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/bundler https://github.com/robbyrussell/oh-my-zsh/tree/master/plugin...
- joelhaasnoot 14y agoI've put 'cd foo' in my post-activate hook, saves a command and could ofcourse be widended to do other environment setup tricks...
- xnxn 14y agoYou might want to consider using the virtualenvwrapper.project extension. You define a "projects" dir (which I had already) and then it binds virtualenvs to projects so `workon foo` automatically `cd`s you to the right place. You can also create a new project dir and virtualenv in one shot with `mkproject`.
- timtadh 14y agoI don't use virtualenvwrapper either. I generally have more stuff to initialise for my projects than just the virtualenv. I use swork[1] a tool I wrote for managing your shell environment. It basically dumps all of your environment variables to a file allowing them to be restored later, then it runs a project specific initialisation script. [1] https://github.com/timtadh/swork https://github.com/timtadh/swork
- mattlong 14y agoAlso a fan of virtualenvwrapper. workon with tab completion (in bash, at least) is so nice when you've got more than a few virtualenvs and can't quite remember your naming scheme :)
- j2labs 14y agoEven though I agree, virtualenvwrapper is currently a shell script. That makes me think it probably wouldn't be included, but a pythonic version of the same thing could exist and fill this gap.
- kibwen 14y agoWhen I first tried to learn Python last year, the frustration of being a first-timer dealing with the Python 2 vs. Python 3 split very nearly turned me off of the language altogether. While I loved the language itself from first sight, Virtualenv was the tool that finally made Python a joy to use, rather than just a joy to write. This is a very good move. Here's the link to PEP 405: http://www.python.org/dev/peps/pep-0405/ http://www.python.org/dev/peps/pep-0405/
- jcurbo 14y agoSo, as someone just dipping their toes into Python, what did you do regarding 2 vs 3? I have been tinkering with 2 but should I go wholly with 3? Help me before I just go back to Perl 5... :)
- sp332 14y agoPython 3 was on a 5-year transition. This was to let the tools develop, give time for major libraries to be ported, etc. We are now more than halfway through, so most of the important libs work fine in Py3. And the syntax is generally nicer, so you might as well start with Py3 today.
- ovi256 14y agoAs a beginner, picking between 2 or 3 should not be one of your concerns, it's a choice that does not unlock much value either way (and it does not hurt much if you pick the 'wrong' way either). I would say start on 2.7, as most of the popular Python libraries are still Python 2.x only, and 2.7 backports some Python 3 features, so you (and your code) will be ready for 3 whenever the world switches over :)
- Anirak 14y agoAlso, why would using virtualenv make anything easier? If anything, it's slightly more of a pain. Once you learn it, it's fine, but it's certainly not something I think about on a daily basis, and it sure isn't impacting my enjoyment of the language.
- 14y ago
- crusso 14y agoThat's good news. Last I looked at virtualenv, though, it could have used more oomph. At the time (last Fall), I was jumping back and forth between Python virtualenv environments and Ruby rvms. RVM was a bit more of a pleasure to use. I hope the virtualenv developers have closed the usability/feature gap since then.
- monkeyfacebag 14y agoCan you be more specific about what you mean by "oomph"? I ask because I'm not familiar with rvms but am familiar with (and love using) virtualenv.
- crusso 14y agoVirtualenv is a nice tool for managing library sets. RVM allows you to do that plus it allows you to install and manage multiple versions of Ruby itself. Want to have side-by-side Ruby environments of 1.8.6 and 1.9.3? No problem. https://rvm.io// https://rvm.io//
- traviscline 14y agoInteresting, I've had an almost opposite experience, but I don't know the ruby landscape all that well (bundler/gemsets/rbenv/rvm etc) and I suppose it just depends on what background you're coming from. FWIW, when creating a virtualenv the -p flag lets you choose a python binary (and therefore version).
- drsintoma 14y agovirtualenv allows you to do that too (virtualenv -p [path to python]). You just need to download the interpreter yourself.
- epochwolf 14y agorvm will download the requested version's source, apply any patches or flags you specify and then compile it. You don't have to do any work other than installing rvm. The rubies are also stored in ~/.rvm so your system doesn't get cluttered up. Rvm also integrates into your shell so that when you cd into a project directory with a .rvmrc file, it will source the file and load the proper ruby and gemset for that project. Virtualenv is much closer to ruby's bundler gem than rvm.
- alaithea 14y agoI only skimmed PEP 405, but did anybody get a sense for how this would work with regard to managing different versions of Python per virtualenv? It seems like a tool to do that necessarily has to be higher in the stack than the Python interpreter.
- stfp 14y agoYou need virtualvirtualenvenv for that.
- daliusd 14y agoI guess the same way as with multiple python interpreters. E.g. under Linux/Mac OS X I might have python python2.5 python2.6 python2.7 and etc. Under Windows I have different locations for different python versions (e.g. c:\python26 c:\python27). You will simply have virtualenv, virtualenv2.6, virtualenv2.7.
- tomrod 14y agoThis is great! I've been wanting to try virtualenv for awhile based on the good things I've heard. Here's to the developers keeping it modern.
- zobzu 14y agoHow are you doing system wide security updates with virtualenv?
- tvon 14y agoThis would have nothing to do with virtualenv, unless I'm misunderstanding you.
- zobzu 14y agoVirtual env installs libraries for your program/web service/etc. Those libraries will eventually need security updates. On Linux for example, which hosts most servers, you upgrade python libraries with yum update/apt-get update/you-name-it. Single central package database, security updates are marked as security, makes upgrades easy and you never miss one. With VirtualEnv your dependencies are installed outside the score of the package manager. It means you have to keep track of security updates yourself. If you don't, and one lib has a well known security bug, you'll be hit and you most likely had no chance to update because "you didn't know". That's why I'm asking. I know a lot of companies hosting python things and using VirtualEnv because "its easy", but they entirely discard updates. I'm not sure that is wise. I was hoping someone had a solution.
- lamby 14y agoThis is one reason I cannot use virtualenv in production. (Also because the build process for your project involves accessing the internet. Yuck.)
- sophacles 14y agoYour parenthetical is just wrong. The setup for a new virtualenv requires access to the internet, iff you choose not to a) bundle the packages in a libs dir or b) have a locally hosted mirror of pypi or c) have the libs in your system packages already or d) a dozen other things. Of course this is true for setting up any development environment. You have to get the dev environment from somewhere at some point to bootstrap the process. Your entire parentheical screams FUD, and obviously disingenuous FUD at that.
- baq 14y agooh god yes. a little bit over 8 years too late, but better late than never.
- obilgic 14y agocan we do that for rubygems too?
- gosub 14y agoDoes anybody else think that the necessity of virtual environments for programming languages and virtual machines for applications is a sign of failure in package management and sandboxing in modern OSes?
- Goladus 14y agoSort of, but they necessarily approach the problem from different vectors. An operating system design with a seamless, straightforward, easy-to-use mechanism for handling all potential dependency conflicts on a multi-purpose, multi-user system is a very hard problem. Any solution is likely to be complex and potentially confusing to users, such as debian alternatives or the modules environment system. Every language has its own library management system: cpan, pip, rubygems, leiningen, etc., and they all profit off the assumption that they are managing a single set of requirements and dependencies. Operating Systems do not have that luxury. On the other hand from the user perspective, they may not even have root on a system and as such may not even be able to install libraries without contacting a system administrator. Maybe it's a shared hosting environment, maybe it's a research compute cluster, maybe there are SOX restrictions on developers, whatever. Virtual environments focus directly on giving the user/app what they need and isolating that user from everything else. 100 different users can use virtualenv to create 100 different, completely not-compatible python environments and they're all happy. How would an Operating System do that, without essentially duplicating what virtualenv already does? (Not saying that OS developers aren't going to try, which Zed Shaw will then ridicule, but that's another story). For sandboxing in general, at what point do you create the sandbox? Usually for each individual app and usedr you don't want to have to answer questions about whether you still want the C++ compiler available or whether a virtualized /etc/passwd is needed. Those are the sort of questions you have to answer when designing OS-level sandboxes.
- gosub 14y ago>> How would an Operating System do that, without essentially duplicating what virtualenv already does? This, I think, is backwards: virtualenv must do it already because the os doesn't. I concede that creating something now may be too late not to suffer the "15 competing standards" effect.