Dealing with multiple versions of packages...

[David Fraser]

Chris Barker wrote:
> 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

How about introducing some new syntax:

import wx where wx.version >= "2.5"

Then we just need a means of determining the version.
You could use a directory name of wx-2.5 for the package rather than wx
Or maybe have an enhanced version of .pth files that specifies package 
attributes.

It would be nice if the above could be combined with the Python Package 
Index to automatically fetch packages...

Davod