Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Dealing with multiple versions of packages...

Reply
Thread Tools

Dealing with multiple versions of packages...

 
 
Chris Barker
Guest
Posts: n/a
 
      04-20-2004
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
 
Reply With Quote
 
 
 
 
Rob Nikander
Guest
Posts: n/a
 
      04-21-2004
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

 
Reply With Quote
 
 
 
 
David Fraser
Guest
Posts: n/a
 
      04-22-2004
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
 
Reply With Quote
 
Graham Dumpleton
Guest
Posts: n/a
 
      04-22-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (Chris Barker) wrote in message news:<(E-Mail Removed) 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dealing with multiple inputfiles at runtime? none C++ 2 05-04-2010 08:18 PM
TreeTop: dealing with Grammars in multiple files? Phil Tomson Ruby 3 02-29-2008 04:25 AM
Dealing with multiple excel sheets Rohan Python 2 08-07-2007 06:31 PM
Dealing with multiple encodings in the same app Isak Ruby 2 03-08-2007 02:21 PM
Dealing with multiple sets John Henry Python 6 10-26-2006 04:45 PM



Advertisments