Perry A. Stoll wrote:
M.-A. Lemburg firstname.lastname@example.org 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
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.