
Virtualenv to be part of Python 3.3 - j2labs
http://mail.python.org/pipermail/python-dev/2012-May/119668.html
======
kibwen
When 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/>

~~~
jcurbo
So, 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... :)

~~~
gecko
Learn Python 2 first, since it's vastly more supported right now, but know
that it's very easy to jump between Python 2 and Python 3, and many people do.
The decision of which to use on any particular project is basically:

    
    
      1. Are you doing web development?  If so, use Python 2.
      2. If not, do you need or want to use PyPy?  If so, use Python 2.
      3. If not, are the libraries you want available for Python 3?  If so, use Python 3.
      4. Otherwise, use Python 2.

~~~
thebigshane
This is discussed rather thoroughly on Python's own wiki:
<http://wiki.python.org/moin/Python2orPython3>

    
    
       Short version: Python 2.x is the status quo, 
       Python 3.x is the present and future of the language

~~~
jasonlotito
You know, I hate to say it, but you, and your parent commenters have basically
said quite a bit without actually answering the question. Anyone coming here
wondering which one to learn is going to be left with the same question, only
slightly more confused.

~~~
thebigshane
I purposefully avoided any attempt to answer the question directly.

How would one know what to recommend while knowing nothing about `jcurbo`s
intentions/designs/requirements?

The stackoverflow and wikipedia communities sometimes get flack about
maintaining strict objectivity, and I know the HN community is allowed to be
different, but surely you agree that there is no right answer to `jcurbo`s
question. And if there is no right answer, surely offering information from a
trusted source can be just as helpful (if not moreso).

tl;dr: Python 3.

~~~
jasonlotito
> How would one know what to recommend while knowing nothing about `jcurbo`s
> intentions/designs/requirements?

For someone learning Python? Just give them your best suggestion. Look, it's
fairly easy.

Learn Python 3. There are differences, and you might run into issues later on,
but once you get to that point, you'll know enough to do something about it.

See, when someone asks whether to learn Python 2 or Python 3, that's what they
are asking for. If they are learning for specific reasons (for a job, lets
say), then instead of trying to answer, you ask follow up questions. But for
learning a language, they are seeking advice from experienced people.

So, when those same experienced people, who already know Python 2 and/or
Python 3 tell them to learn Python 2 and/or Python 3, they are being told: we
don't know.

And how is someone inexperienced supposed to know which one to learn when
experienced people don't know?

Basically, if you can't answer the question because you feel you lack
information, ask. Otherwise, answering the question "Learn Python 2 or 3?"
with the answer "Learn Python 2 or 3." isn't helpful.

------
famousactress
Awesome! 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
I'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/plugin...](https://github.com/robbyrussell/oh-my-
zsh/tree/master/plugins/bundler)

~~~
timtadh
I 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>

------
gosub
Does 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
Sort 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
>> 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.

~~~
Goladus
You can always install from source and pass --prefix and --exec-prefix options
to ./configure. Virtualenv is not strictly necessary to run in an isolated
environment.

And as for whether virtualenv should have been part of the OS... it already is
in some cases, to the extent that any userland tool is part of the OS.

    
    
        $ uname -o
        GNU/Linux
        $ which virtualenv
        /usr/bin/virtualenv
    

Does it really matter whether it was the python developers who got there
first?

------
zobzu
How are you doing system wide security updates with virtualenv?

~~~
tvon
This would have nothing to do with virtualenv, unless I'm misunderstanding
you.

~~~
zobzu
Virtual 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
This is one reason I cannot use virtualenv in production.

(Also because the build process for your project involves accessing the
internet. Yuck.)

~~~
sophacles
Your 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.

------
crusso
That'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
Can 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
Virtualenv 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//>

~~~
drsintoma
virtualenv allows you to do that too (virtualenv -p [path to python]). You
just need to download the interpreter yourself.

~~~
epochwolf
rvm 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.

~~~
sirn
It's much closer to _rbenv_ rather than Bundler. zc.buildout is what is close
to bundler.

------
alaithea
I 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.

~~~
daliusd
I 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
This 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.

------
obilgic
can we do that for rubygems too?

------
baq
oh god yes. a little bit over 8 years too late, but better late than never.

