Dealing with multiple versions of packages...

[Chris Barker]

Hi all,

We've been having a discussion over on the wxPython-users mailing list
about how to deal with multiple versions of wxPython. During the
discussion it came up that this isn't a problem faced only by
wxPython, but would have to be dealt with by virtually all packages.

The root of the problem is what to do when you install a new version
of wxPython, and want to be able to keep using the old one. This
question comes up frequently on the users list, and various schemes
are used by a variety of people. These schemes mostly involve having
some sort of script that re-names or re-links the site-packages/wx
directory, so the chosen version can be used.

This works fine if your goal is to be able to switch back an forth for
testing, and during the process of moving your app(s) to a new
version.

However, my goal (and I don't think I'm alone) is to have both
versions installed and working at the same time, and have the app able
to select between them. I want this because I have a bunch of small
utilities that use wxPython, and I don't want them to break when I
upgrade, forcing me to go back and port all of them to a new
version...if it ain't broke, I don't want to fix it. What I would like
is analogous to using:

#/usr/bin/env python2.2

and

#/usr/bin/env python2.3

at the top of my python programs... I can have all my old 2.2 scripts
work just fine, while I write new ones for 2.3.

The easiest proposal is:

1) wxPython gets installed into:

site-packages/wxXXX  (with XXX) being the version number

You could put a link to wx if you want, so as not to change anything
for people who don't want to change.

For this to work, ALL the stuff in the demo and libs would have to
import this way"

import wxXXX as wx

This creates problem when the user needs sub-packages:  This won't
work:

import wx251 as wx
import wx.lib.buttons

Which I think points out a problem with the package import mechanism,
but I won't go there at the moment....

Another proposal is:

2) put wx251 deeper in the structure:

from wxPythonVersions.251 import wx
from wxPythonVersions.251 import wx.lib.buttons

wxPythonVersions (or a shorter, catchier name) would live in
site-packages. You could put a symlink:

site-packages/wx --> site-packages/wxPythonVersions/251/wx

for backward compatibility.

I think this would work great, but I also think there will be a strong
push to have a default:

import wx

which would require a symlink, and you can't symlink on Windows.

So ... What have other folks done to deal with this?
Would either of the above methods work well?
What pitfalls am I missing?
Is there a standard Pythonesque way to handle this?

-Chris