P
Paul Smith
One thing I always liked about Perl was the way you can create a single
installation directory which can be shared between archictures. Say
what you will about the language: the Porters have an enormous amount of
experience and expertise producing portable and flexible interpreter
installations.
By this I mean, basically, multiple architectures (Linux, Solaris,
MacOSX, even Windows) sharing the same $prefix/lib/python2.7 directory.
The large majority of the contents there are completely portable across
architectures (aren't they?) so why should I have to duplicate many
megabytes worth of files?
The only parts of the install which are not shareable (as far as I can
tell) are the .so dynamic objects (and the python executable itself
obviously).
If the default sys.path included platform-specific directories as well
as the generic lib-dynload, it would be possible.
I do see that there are "plat-*" directories available in the default
path. Is it possible to make use of these (say, by renaming each
architecture's lib-dynload to the appropriate plat-* name)?
If that works, the remaining issue is the site-packages directory.
There is no ability (that I can see) to separate out the shareable vs.
non-sharable aspects of the add-on site-packages.
Any comments or suggestions? Am I overestimating the amount of sharing
that's possible? Thanks!
installation directory which can be shared between archictures. Say
what you will about the language: the Porters have an enormous amount of
experience and expertise producing portable and flexible interpreter
installations.
By this I mean, basically, multiple architectures (Linux, Solaris,
MacOSX, even Windows) sharing the same $prefix/lib/python2.7 directory.
The large majority of the contents there are completely portable across
architectures (aren't they?) so why should I have to duplicate many
megabytes worth of files?
The only parts of the install which are not shareable (as far as I can
tell) are the .so dynamic objects (and the python executable itself
obviously).
If the default sys.path included platform-specific directories as well
as the generic lib-dynload, it would be possible.
I do see that there are "plat-*" directories available in the default
path. Is it possible to make use of these (say, by renaming each
architecture's lib-dynload to the appropriate plat-* name)?
If that works, the remaining issue is the site-packages directory.
There is no ability (that I can see) to separate out the shareable vs.
non-sharable aspects of the add-on site-packages.
Any comments or suggestions? Am I overestimating the amount of sharing
that's possible? Thanks!