[Distutils] easy_install and Unix python with sys.prefix different from sys.exec_prefix

[Berthold Höllmann]

"Phillip J. Eby" <pje at telecommunity.com> writes:

> At 03:22 PM 11/1/2006 +0100, Berthold Höllmann wrote:
>>Is there a way to fix these problems?
>
> Set your desired installation paths in one of your configuration files; see 
> the easy_install docs for details.
>
> Note, however, that easy_install doesn't have to install to different 
> locations for platform-specific code, because it installs files or 
> directories that include platform information in the filename!  So, there's 
> nothing wrong with having a single shared installation directory, as long 
> as you use --multi-version to allow different platform versions to 
> co-exist, without having a default version.
>
> The downside to this approach is that if you start the Python interpreter 
> manually instead of via a setuptools-based #! script, then the packages 
> will not be importable without first calling require().  Of course, you can 
> remedy that with a sitecustomize.py containing e.g.:
>
>      from pkg_resources import require
>      require('somepkg', 'otherpkg', ...)
>
> Which would do basically the same thing as having an easy-install.pth, 
> except that it's not platform-specific.
>
> The other alternative to this is that you simply use your NFS directory as 
> a cache for easy_install.  The way this would work is that you install 
> things with two easy_install steps for each platform:
>
>      easy_install -zmaxd /path/to/shared/directory SomePackageName
>      easy_install -f /path/to/shared/directory SomePackageName
>
> The first line will download/build/etc. and just dump the eggs to the 
> shared directory, without creating a .pth or scripts, etc.  Then, the 
> second line will install the .pth and scripts, assuming you've configured 
> easy_install's library and script installation directories to be your 
> platform-specific directories.  (Note: you would have to have a 
> platform-specific scripts directory, because the #! line is going to point 
> to the platform-specific Python.)
>
> This approach allows you to avoid re-installing platform-generic libraries, 
> because they will be found in the cache directory without downloading.

After being away from this stuff for a while I want to it. Is there a
technical reason for not honoring the difference between "--prefix"
and "--exec-prefix" in setuptools the way python and distutils do?
With distutils an extensions will be installed into the "exec prefix"
path and a module into the "prefix" path. For our purpose I moved the
extensions extensions out of the "prefix" site-packages directory into
the "exec-prefix" site-packages directory, removed the according lines
from the easy-install.pth in the "prefix" tree and copied them to a
hand written easy-install.pth in the "exec-prefix" trees. The
installation seems to work.

I must concede that distutils also have problems with the shebang
lines when installing packages. For our own distutils based
installations I use

from distutils.command import build_scripts
build_scripts.first_line_re = re.compile(r'^###!.*python(\s+.*)?$')

to fix the shebang line, or better said for not to fix the
line. Distutils are looking for the wrong line to replace now. For
third party modules I usually fix the shebang lines by hand after the
installation from "<exec-prefix>/bin/python" to "/usr/bin/env python"
by hand, but a way of site wide customization would be great.

If the problem with implementing my wishes is less technical than lack
of available work force, I would be happy to help out, if someone
could give me some hint where in the source to look.

Thanks
Berthold
-- 
                            __   Address:
                         G /  \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 35       P.O.Box 111606
fax  : +49-40-36149-7320   \__/   D-20459 Hamburg    D-20416 Hamburg