[Distutils] Packages with C extensions

[M.-A. Lemburg]

Perry A. Stoll wrote:
> 
> > M.-A. Lemburg <mal@lemburg.com> writes:
> 
> >[Problem with dynamic extensions in packages being platform dependent]
> >
> >I haven't followed the thread too closely, but was alarmed by
> >the recent proposals of splitting .so files out of the "normal"
> >package distribution under a separate dir tree.
> 
> Fair enough. There's the the GNU configure view of life, where $prefix and
> $exec_prefix are separate directories, and there is the perl view of life
>  $PERL_ARCHLIB is usually a subdirectory of the install directory). M.A.
> prefers the perl-ish approach. Fine with me, as long as we do it explicitly.
>
> > (you can't have two top-level packages with the same name
> >on the path: only the first one on the path will be used).
> 
> That's only because that's how it's done today. Just a matter of some
> code...(and the thought and design behind it).

Good point :-) ... having Python continue scanning the path after
some import fails would definitely ease structuring of packages,
mostly because it allows extending existing installations with
user or platform specific modules.

The latter is a basic building block for a possible future standard
Python lib with a package layout (see a discussion about this on
c.l.p last year, I think).
 
> >  [ snipped scheme for having packages do the platform specific import ]
> 
> I'd rather not burden the package writer. I think it's better to include the
> batteries for this one.

Fair enough, but I guess a simple platform aware import helper
would do the trick nicely, e.g.

MyModule = platimport('MyModule')
 
> >  [recommendation that you just have a different install dir for each
> platform ]
> > Disk space is no argument nowadays
> 
> Ease of maintenance is the overriding argument here. The .py files are the
> same for all platforms so why do I want different copies of those files when
> I have python install for three platforms?

The latter gets defeated by the disk space non-argument. Also, some
future version of Python may very well use platform dependent optimized
versions of .py files, e.g. JIT compiled ones.

Besides, I don't think that a simple 'cp -a plat-1 plat-2' causes
too much maintenance effort ;-) If you worry about disk space, you
could even setup a linked copy for the new platform using e.g.
Tools/scripts/linktree.py.

> > its likely that different platforms need different Setup files anyway.
> 
> But that's a platform dependent file which goes in the $INSTALL_ARCHLIB.

True. Not sure why you would want to install that file though (its only
needed for compilation).
 
> In short, I think we need to get this infrastructure into Python itself to
> ease the creation of package authors.

Now, I think, you're taking the idea a bit too far ;-) ...

> But then I'm probably preaching to the
> choir.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Y2000:                                                   220 days left
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/