Workingenv is dead, long live Virtualenv!

A lot of people have found workingenv useful, but it’s always been a bit fragile. If you’ve seen the .../ is not a setuptools-generated; please remove it. message, you know what I mean.

For a while I tried to refactor and improve workingenv, but it didn’t go very well. So I decided to ditch it completely and revisit the ideas of That script works by copying the Python executable, and in doing so change sys.prefix — it’s pretty consistent that all other paths in Python derive from sys.prefix.

The result is virtualenv, which I think is now featureful enough for general use. It might still be buggy, but it’s worked well for some of us, and I expect the bugs to all be much easier than they were in workingenv.

Unlike, virtualenv works on Windows and in the latest release also Mac framework builds. It also handles site-packages better, so you can manage some of your packages using packages from your OS distribution (e.g., debs or rpms), while also installing environment-local packages.

So, in summary: use virtualenv, don’t use workingenv. And if you were using the --requirements option to workingenv, the package PoachEggs lets you do a similar batch installation after you’ve created the environment.

Automatically generated list of related posts:

  1. pyinstall is dead, long live pip! I’ve finished renaming pyinstall to its new name: pip. The...
  2. Monkeypatching and dead ends Bill de hÓra and then Patrick Logan picked up on...
  3. 2 Python Environment Experiments two experiments in the Python environment. The first is virtualenv,...