[Python-Dev] Relative Package Imports

[M.-A. Lemburg]

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/