Dealing with multiple versions of packages...

Discussion in 'Python' started by Chris Barker, Apr 20, 2004.

  1. Chris Barker

    Chris Barker Guest

    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
     
    Chris Barker, Apr 20, 2004
    #1
    1. Advertising

  2. Chris Barker

    Rob Nikander Guest

    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
     
    Rob Nikander, Apr 21, 2004
    #2
    1. Advertising

  3. Chris Barker

    David Fraser Guest

    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
     
    David Fraser, Apr 22, 2004
    #3
  4. (Chris Barker) wrote in message news:<>...
    > 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.
     
    Graham Dumpleton, Apr 22, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul  Smith
    Replies:
    0
    Views:
    734
    Paul Smith
    Nov 18, 2003
  2. Replies:
    6
    Views:
    475
    Patrick May
    Nov 19, 2005
  3. Logan
    Replies:
    5
    Views:
    321
    Doveclaw
    Nov 26, 2003
  4. David Bishop
    Replies:
    0
    Views:
    464
    David Bishop
    Jun 20, 2007
  5. Jabba Laci
    Replies:
    1
    Views:
    1,292
    alex23
    Sep 27, 2011
Loading...

Share This Page