[Distutils] Odd limitation in packaging/distutils2

[Ned Deily]

In article <4EB41FF3.1080304 at netwok.org>,
 Éric Araujo <merwok at netwok.org> wrote:
> Le 04/11/2011 13:11, Mark Hammond a écrit :
> > On 4/11/2011 3:53 AM, Paul Moore wrote:
> >> Agreed, it's not good. It's just that I don't know (on Windows) what
> >> things *do* make a Python build "installed". I'll see if I can find a
> >> definitive statement from somewhere...
> > 
> > There really isn't anything that makes it "installed".  A built Python 
> > works completely fine just where it is (and indeed, will work just fine 
> > if moved somewhere else).  The closest thing to being "installed" on 
> > windows is an "InstalledPath" (or something :) registry key for the 
> > version, but that is only necessary in a limited number of contexts - 
> > when some executable other than the in-place python[w].exe needs to know 
> > where things are.
> 
> Ah, okay.  The situation is different on UNIX: Installing Python
> typically writes the file in read-only mode (one consequence: users have
> to call setup.py --user, use virtualenv or switch to the superuser to
> install things), and does not just copy the build dir (so missing data
> files in the Makefile cause bugs that can only be seen when running the
> test suite or other code from an installed Python).

One other very important difference: if the build was configured as 
--enable-shared, the final installed path to the shared library is 
usually captured in the built python executable.  On most Unixy 
platforms that means you *cannot* reliably run the python executable 
from the build directory without taking some steps to override the 
default dynamic library search path, i.e. usually LD_LIBRARY_PATH.  In 
the best case, the interpreter fails to start; in the worst, you get 
deceptive behavior when the newly built interpreter executable actually 
runs with a previously installed shared library.  This is also true for 
OS X framework builds, which are a special kind of shared-library builds.

-- 
 Ned Deily,
 nad at acm.org