Re: [Distutils] Packages with C extensions

M.-A. Lemburg <mal@lemburg.com> writes:
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 ]
[recommendation that you just have a different install dir for each
I'd rather not burden the package writer. I think it's better to include the batteries for this one. 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?
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. -Perry

Perry A. Stoll wrote:
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).
Fair enough, but I guess a simple platform aware import helper would do the trick nicely, e.g. MyModule = platimport('MyModule')
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/

Perry A. Stoll wrote:
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).
Fair enough, but I guess a simple platform aware import helper would do the trick nicely, e.g. MyModule = platimport('MyModule')
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/
participants (2)
-
M.-A. Lemburg
-
Perry A. Stoll