Re: PEP: import version
From: Christopher Barker (Chris.Barker_at_noaa.gov)
Date: 05/14/04
- Next message: SeeBelow_at_SeeBelow.Nut: "Where do I find what colors and fonts are available?"
- Previous message: Jorge Godoy: "Re: Help with Distutils"
- In reply to: Skip Montanaro: "Re: PEP: import version"
- Next in thread: A. Lloyd Flanagan: "Re: PEP: import version"
- Reply: A. Lloyd Flanagan: "Re: PEP: import version"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 13 May 2004 15:51:59 -0700
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@noaa.gov
- Next message: SeeBelow_at_SeeBelow.Nut: "Where do I find what colors and fonts are available?"
- Previous message: Jorge Godoy: "Re: Help with Distutils"
- In reply to: Skip Montanaro: "Re: PEP: import version"
- Next in thread: A. Lloyd Flanagan: "Re: PEP: import version"
- Reply: A. Lloyd Flanagan: "Re: PEP: import version"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
