Virtualenv bin/activate isn't doing anything "wrong". It's just not doing it how the author believes is best. Can the whole "You're doing X wrong" meme die already please?

I like the idea though! From what I see so far the author makes a good argument for using a subshell rather than setting and resetting environment variables. At the same time though, I haven't enough experience with his suggestion yet to see the downsides... and there most definitely will be. Why? Because that's programming, man. There's no panacea, no perfect way to do things, no true "best" way to do anything.

So is this the "right" way? Probably not. Better is probably more like it and using that word instead makes you seem, you know, like not cocky asshole (not that I think that about the author at all, just generally speaking).

The fact that it does not use a subshell makes it useful. You can trivially use it in bash scripts and cronjobs.

  #!/usr/bin/virtual-bash my-env
  
  echo hello

Venv is one of the pieces of sanity in the python packaging deployment world and any improvements welcome - this goes on my List if things to think hard about

Reading the Google Groups responses, he's officially created a http://xkcd.com/1172/ situation heh

I handle this issue (and a bunch of other environment variable issues) with a little utility I wrote.

https://github.com/timtadh/swork

It basically figures out the pid of your shell and dumps the environment variables into a file in /tmp/swork. Then you make custom activate scripts for all of your projects. It has really helped me deal with a lot of projects. It also has convenience functions for quickly cd'ing to any project.

When you want to get back to the original configuration it simply restores the original environment vars.

The approach i use is simply:

    $ cat run
    #!/bin/sh
    . venv/bin/activate
    python main.py

Is this wrong? If so, what would work better?

I haven't used activate in years, I just call the interpreter directly.

None of these problems are the kinds of problems I've ever run into. They're entirely a series of what if and edge case scenarios in which virtualenv is not the answer, which is fine. I don't need a tool that can do things I'm never going to do.

This is also the same technique I like to use for providing configuration to applications. Basically, write YOUR_APP_ENV=prod or whatever into /etc/environment and then add appenv to PATH which tests against the machine's environment, sets all the appropriate environment variables accordingly and ends with an `exec`. Super nice way to provide shell-friendly language-agnostic configuration.

I used to use `exec env $@` at the end of the script, so that I could `appenv > prod` for diffing, but I actually prefer this articles suggestion: `exec "${@:-$SHELL}"` since you can still `appenv env > prod`, but `appenv` provides an interactive shell by default.

But what will be the added CO2 footprint of launching so many unnecessary shells!

Also, I don't like the prospect of having to hit Ctrl-D twice to logout.

Ah, I like this. I'm going to cavort off with these ideas and put them to good use in my rubygems environment switcher gemenv.

This is also how all HPC computing environments (such as SLURM, SGE) do it. They simply spawn a subshell for you to work with and do whatever you want to run.

...and Python 3.3 just included virtualenv as a standard library...