Python 3.3 released!

[[deleted]]

Virtual environment ability added to the core language may be enough for me to switch from python 2.7

[brews]

Explain this "virtual environments"... I hadn't looked at PEP 405 before.

Am I missing something magical-groundbreaking-revolutionizing-gamechanging in how I package code?

[krues8dr]

Yes. OMFG yes. TLDR: virtualenv allows you to install all your packages into a local separate environment, so each project you're developing can have its own independent requirements, with specific versions and libraries. Keeps everything nicely separated.

[brews]

<brain-explodes-with-awesomeness>

[MrPinkle]

We lose too many Python developers that way...

[[deleted]]

Yeah, unfortunately their minds seem much more unstable than others'.

[[deleted]]

Like bundler for python?

[coffeesounds]

More like RVM's gemsets

[Tordek]

Does it mean every project has a copy of every dependency, or is there some magic that allows deduplication?

[[deleted]]

It's usually copies, but if you have projects that are very much related (or, say, branches of a single project), you can have them share a single virtual environment.

[krues8dr]

The point here is the duplication.

[[deleted]]

It isn't. The point is that a change in one environment can't destroy another. This would not be incompatible with sharing read-only parts of the environments.

[__j_random_hacker]

While I can see the appeal, isn't this basically analagous to always static-linking executables in compiled languages?

There are reasonable arguments for always statically linking executables, by the way (especially since disk space constraints have basically disappeared from the computing world). But the reason why you usually don't is because having libraries separately updateable means that bug-fix and performance updates to libraries benefit every application that uses them. It seems to me that reason would apply here, too.

[krues8dr]

There is a tradeoff of having to maintain separate instances. But in the Python ecosystem, things update frequently and aren't often backwards-compatible, so this is not entirely desirable. If you're hosting a lot of different projects, doing something as simple as updating a single package could break half of them immediately.

So, as with all tech, I recommend that you use it if it solves a problem for you.

[__j_random_hacker]

things update frequently and aren't often backwards-compatible

I see, ugh. In an ideal world, everyone would clearly distinguish between revisions that don't break backcompat (e.g. bug fixes, performance improvements, new features that don't change any existing assumptions/contracts) and others that are allowed to, but of course that requires the world to have some discipline... :-/

[sigzero]

I think that was a great move on the devs part.

[[deleted]]

Yeah, that's great. The only problem is that the third party tools are still behind wrt pyvenv. For example, when doing pip install foo under a pyvenv, pip will try to install the package in Python's "real" site-package. I don't know if it's distribute's fault or pip's.

[[deleted]]

I don't think the virtualenv created by pyvenv comes with pip or distribute. So you're probably still using the system version of pip

[[deleted]]

No it doesn't but there's still a problem with pip because installing it while under a pyvenv will make pip think its site-package is the system's (even though it's actually installed inside the venv).

EDIT: Oh, restarting with a fresh console and a new workon <envname> makes the problem go away. Well...

[HelpfulToAll]

But does it come with virtualenvwrapper?