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

[Rob Nikander]

I haven't heard of a standard way to do it.

I downloaded PyGTK 2.0.x a while back and I remember looking at a
package structure that looked like it was designed to do this. You
might want to check that for ideas. (I don't have it on my machine now.)

Also I was using a python module today that behaved differently upon
import, depending on a property of "sys". Like:

import sys
sys.coinit_flags = 0
import pythoncom # initializes COM with sys.coinit_flags

In your case wx could be a package with an __init__.py that imported
subpackages depending on what version was set (with a default of
course). To import packages based on a string variable you have to use
__import__.

You could also set PYTHONPATH to the version you want. ?

Rob

[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

[Graham Dumpleton]

Ch**********@noaa.gov (Chris Barker) wrote in message news:<62*************************@posting.google.c om>...

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.

Check out Pmw (pmw.sourceforge.net) for ideas. It stores stuff under a
root of Pmw, but then has separate directories under that for each version.
Ie., Pmw_1_1, Pmw_1_2, etc. The __init__.py in the root is then a special
lazy loader which by default uses the latest version, but you can specify
a specific version by using a setversion() method. Whatever version you
end up using, everything is still referenced as Pmw.SomeClass rather
than having to hard code the version everywhere.