PEP: import version

Thu May 13 18:51:59 EDT 2004

Skip Montanaro wrote:

> Perhaps I'm missing something...  If you need to futz around at runtime,
> futz around with sys.path.  Can you summarize the wxPython discussions for
> those of us who don't use that toolkit (and have apparently never run into
> this problem in such an intractable way that we felt the need to change
> Python because of it)?

Actually, I was personally advocating an approach that did not require 
changing python, but would hopefully be standardized. I posted a 
question to this newsgroup about it a short while back, and I think 
PyGTK and PMW both do this in some way or another, so it's not a totally 
unique problem.

> In particular it would be helpful to understand why
> you don't know what version of wxPython you want to use before running > the program.

I know what version I want when writing it, but not necessarily when 
running it. This is analogous to why I ALWAYS use:

#!/usr/bin/env python2.3

rather than:

#!/usr/bin/env python

at the top of my scripts. RedHat doing the later created a major 
pain-in-the-behind for many of us. I only wish there were a way for 
Windows Python to handle that kind of thing gracefully. MacPython uses a 
"PythonLauncher" mini-app to take care of it (and for other reasons).

Anyway, as for wxPython (and many other packages, I imagine), I have a 
handful of small utilities that work just fine with Python version X and 
wxPython version Y. If I upgrade python while keeping the old one in 
place, they all still work (thanks to my specifying the version on the 
#! line), However, if I add wxPython version Z, I'm stuck. The way it's 
ordinarily installed is in site-packages/wx. If I do a standard install, 
it blows away version Y, and all my existing programs are broken. What 
I, and other "early adopters" of new versions do is do a custom install 
and run a script that re-names or sym-links site-packages/wx to the 
version we want. That helps, but then at any given moment, only one is 
the active version, so I can't run a new and old program at the same 
time. So what some of us would like is for the standard way that 
wxPython is installed to allow for versioning. The Wiki page pointed to 
earlier has some suggestions about how to do this.

>     Chris> Basic Goals:
>     Chris> * Multiple versions of wxPython being installed at the same time 

> Presumably in different directories, so setting PYTHONPATH, LD_LIBRARY_PATH,
> etc will distiguish them for applications.

Well, yes, but unfortunately, the standard install puts it in 
site-packages, so you have to do a custom install to make this work.

>     Chris> * Two or more programs, each using a different version could run
>     Chris>   at once. This doesn't require a change to the language.  This requires a proper
> setting of PYTHONPATH and/or LD_LIBRARY_PATH, etc.

Well, yes, but that's a PITA that I don't want to have to go through. I 
want to be able to distribute apps also, and not everyone is going to 
have the same paths as me, and certainly not the same on different OSs.

> Chris> * Easy for developers - for testing with multiple versions etc
>
> That's fine, and precludes the use of something like a hardcoded
>
>     import wxPython version '2.4'

No, it doesn't. Change the 2.4 to 2.5 and you test again. However, there 
have been requests for:

> a
> WXPYTHON_VERSION environment variable which the wxPython framework could use
> or for setting PYTHONPATH.

yup, that's one option, but good for developers, not good for users.

>
>     Chris> * Easy for users - their apps detect the right version to run
>     Chris>   with

> Getting the right version of dependent packages is an installation issue.
> This should be detectable from either configure script, Makefile or
> distutils setup.py script.

Actually this is poorly worked, I don't want the app to detect anything, 
I want to to specify something:

import wx-2_5 as wx

for instance.

>     Chris> * Cross-Platform solution
>
> Distribute your apps with .bat file front ends on Windows, shell scripts
> on Unix.

Yuck, yuck yuck! First of all, I don't know a .bat from a hole in the 
ground (though I suppose I need to learn this to deal with python 
versioning anyway..sigh), and second of all, I'd much rather not have to 
write a wrapper script around a twenty line utility script (or a 2000 
line one either!), and third of all, the wrapper script would be 
platform and individual system dependent

>     Chris> * The ability for the programmer to specify the version used in
>     Chris>   the code, ideally only on (or before) the first import of
>     Chris>   wxPython 

> I fail to understand why that's a problem that needs to be addressed in the
> Python program.  This is information which is know before the program is
> run.  It belongs in an environment variable or front-end shell/bat script.

A front-end script script is one solution to these problems, but it's 
another layer I would rather not have to deal with! Another issue is for 
OS_X BundleBuilder Bundles. You can build them to use the Python 
installation, so I'd like to be able to to the version specifying inside 
the python script, not outside of it.

>     Chris> * The ability to specify the version wanted with an environment     Chris> variable, so that multiple versions could be easily tested
>
> This is the correct way to do this.

It is ONE way to so it, not THE way.

>     Chris> * The ability to specify multiple versions that all work, in a     Chris>   ordered list of some sort.
> Your installation program should detect all installed versions and pick the
> latest version which intersects with the set of multiple working versions.

Again, simple solutions for simple problems. I don't want to write a 
complex installer. Frankly, I think this is getting too fancy (though it 
would be nice). I'm just as happy to have my apps Require a particular 
version, that way I know I've tested there. Disk space it cheap.

>     Chris> * The ability to specify a "minimal" version, and higher versions     Chris> could be used.
>
> Again, this goes in your setup.py script (or configure, or Makefile, or
> whatever).  It's an install-time decision.

Again with the installer! What's wrong with dropping a script in 
/usr/local/bin? Granted when you get beyond small utilities, there is 
often a need for a proper installer, but in that case, you could be 
building stand alone apps with PY2EXE or whatever anyway.

>     Chris> * The ability for "from wx.lib import Something" to work as well,     Chris>   respecting the version

> Assuming your installation software worked correctly this should be a
> no-brainer. ;-)

This was addressing why you couldn't just do:

import wx-2_5 as wx

because then you'd have to change all the "wx" to "wx-2-2_5" everywhere 
else which could get ugly. One thing that makes this harder, at least 
for wxPython, is that there is a legacy way that wxPython has been 
installed and imported, and people would like to preserve that, so that

import wx

and

from wx.lib import Something

and

import wx.lib.Something

need to all still work.

By the way, as my thought about this started with wxPython, and now I'm 
advocating a more general solution, I realize there are some 
differences. A big one is that you could never use more than one version 
of wxPython in a single program, but you might very well be able to use 
multiple versions of other packages in the same program. So, while for 
wxPython it makes sense for __main__ to specify the wxPython version, 
and all other modules that "import wx" get than version, this may not be 
the case with other packages, where each module using it might want a 
different version.

This is really analogous to shared libraries. I see a Python package as 
no different to a shared lib in function. When you compile and link and 
app, the version of the shared lib is specified. When it is run, the 
linker looks for an links that version. The user doesn't have to set an 
environment variable first, or change the lib path, or anything else. 
All I'm looking for is that same functionality. Does anyone remember the 
old DOS days of DLL hell? why would we want that? (Is Windows any better 
now? I'm wouldn't know)

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov