Gordon McMillan wrote:
[MA Lemburg]
The solution I'm using (and Zope is too) is to wrap a complete Python installation into the product, all setup to do the right thing. It makes the archive a little heavier... which is actually not so bad from a marketing POV. Bizarre, but people seem to want all those megs.
This is fine if you're distributing an app - it's a black box, it's standalone, no dependencies outside the app. Cool. I do that too. I use imputil to serve modules out of archives - no need to tweak the modules at all. In the upcoming version (of my installer) sys.path has exactly one entry, and the only python that needs to be outside an archive is exceptions.pyc.
(I repeat here: while the pieces of my installer that handle binary dependencies are Win32 only, the parts that handle pure Python are cross-platform.)
But both you and Jim are aiming for this non-existant in- between space - in some respects you want a "normal" Python installation, but you want to black-box your turf.
Actually, I want my stuff to be as flexible as possible. Of course I'm using it in my product too, but that's a different story. I have the unsatisfying impression that this discussion doesn't lead anywhere. I can't really understand all the evil sides Tim and Guido seem to see in their views of relative imports. For people like Jim and me, who have quite some experience in doing Python packages, this small (! hey, it's only about 20 lines of code !) additional feature could be of great use. I'm still waiting for some ultimate argument that blows relative imports away. The arguments put forward so far have all been in the category "evil", "ugly", "I don't like it". Hey, we can do better than that... Note that if this doesn't work out, Jim and I could always agree on some standard import hook that we'd both use, but that's exactly what we would very much like to avoid in favour of some established standard hard-wired into the Python distribution.
I'm sorry, but if you're going to fit into a Python installation, you should make public your dependencies. Yes, installation becomes more complicated, but you're dealing with *Python users*. They're at least as likely to get screwed by having multiple different copies of the same thing around as you are in having dependencies outside of your personal control.
I am probably going to ship all the mx* stuff in one big package -- not as separate packages anymore. That way I can write code which depends on other parts of the mx universe more easily.
If you also want to distribute as a standalone, freeze/squeeze/ whatever it. Just make sure that what you distribute this way won't interfere (or be confounded by) any existing Python installations.
It won't interfere with anything since the Python interpreter I use is configured *not* too look in any standard places for extensions and the like. Plus it's configured to run faster, but that's a different story ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 108 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/