Home/ Questions/Q 784487
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T20:43:18+00:00

short version: how can I get rid of the multiple-versions-of-python nightmare ? long version:

  • 0

short version: how can I get rid of the multiple-versions-of-python nightmare ?

long version: over the years, I’ve used several versions of python, and what is worse, several extensions to python (e.g. pygame, pylab, wxPython…). Each time it was on a different setup, with different OSes, sometimes different architectures (like my old PowerPC mac).

Nowadays I’m using a mac (OSX 10.6 on x86-64) and it’s a dependency nightmare each time I want to revive script older than a few months. Python itself already comes in three different flavours in /usr/bin (2.5, 2.6, 3.1), but I had to install 2.4 from macports for pygame, something else (cannot remember what) forced me to install all three others from macports as well, so at the end of the day I’m the happy owner of seven (!) instances of python on my system.

But that’s not the problem, the problem is, none of them has the right (i.e. same set of) libraries installed, some of them are 32bits, some 64bits, and now I’m pretty much lost.

For example right now I’m trying to run a three-year-old script (not written by me) which used to use matplotlib/numpy to draw a real-time plot within a rectangle of a wxwidgets window. But I’m failing miserably: py26-wxpython from macports won’t install, stock python has wxwidgets included but also has some conflict between 32 bits and 64 bits, and it doesn’t have numpy… what a mess !

Obviously, I’m doing things the wrong way. How do you usally cope with all that chaos ?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Some tips:

    • on Mac OS X, use only the python installation in /Library/Frameworks/Python.framework.
    • whenever you use numpy/scipy/matplotlib, install the enthought python distribution
    • use virtualenv and virtualenvwrapper to keep those “system” installations pristine; ideally use one virtual environment per project, so each project’s dependencies are fulfilled. And, yes, that means potentially a lot of code will be replicated in the various virtual envs.

    That seems like a bigger mess indeed, but at least things work that way. Basically, if one of the projects works in a virtualenv, it will keep working no matter what upgrades you perform, since you never change the “system” installs.

    • 0