M.-A. Lemburg email@example.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).
[ 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.
[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?
its likely that different platforms need different Setup files anyway.
But that's a platform dependent file which goes in the $INSTALL_ARCHLIB.
In short, I think we need to get this infrastructure into Python itself to ease the creation of package authors. But then I'm probably preaching to the choir.