[SciPy-dev] issues with installing Numeric in a user directory

[Perry Greenfield]

Eric Jones writes:
> (2) .pth files
> Numeric is a "package" that doesn't really behave as a package.  It
> dumps all of its files in site-packages/Numeric, but it doesn't define a
> __init__.py file.  Instead, it also puts a Numeric.pth file in
> site-packages that tells python to also search site-packages/Numeric for
> modules.  This works fine when Numeric is installed as root, but it
> doesn't work when it is installed in non-standard places.  This is
> because .pth files are only expaneded when they exist in the "system"
> locations.  They are ignored anywhere else in the search path.  As a
> result, after installing Numeric with "python setup.py install
> --prefix=$OSDIR", importing Numeric fails even if 
> 
> PYTHONPATH=$OSDIR/lib/python2.2/site-packages
> 
> The fix is easy for someone who understands what is going on -- add
> $OSDIR/lib/python2.2/site-packages/Numeric to the PYTHONPATH.  However,
> the uninitiated may flail around a long time trying to figure out why
> installing a package to there standard location doesn't work --
> especially if it has worked for every other package they have installed.
> 
Something we have done locally at STScI is to hack a sitecustomize.py
file to do what someone else suggested, i.e., to look at all directories
in the pythonpath for .pth files. Our version of this file then looks
to see if it has masked any other sitecustomize.py files in the path
and executes the next one (so as not to screw up existing sitecustomize.py
files). Is this a possible solution?

> I haven't figured out a nice work around here, other than actually
> making Numeric a real package which I doubt is even close to an option.
> Does anyone else have a better solution?
> 
Well, we were going to ask about that eventually (for numarray).
This spurred me to raise it now. Should numarray use the package
mechanism? This would mean that one would do things like

from numarray.FFT import * 

or

from numarray import FFT

The advantages are that numarray 3rd party modules or add-ons are 
more cleanly segregated from the numarray files, and it eliminates 
the possiblity of name collisions with other modules not related
to numarray. Currently we have a problem with the 3rd party modules
in that we have to give them a different name than the equivalent
versions for Numeric (because of name collisions). Thus FFT becomes
FFT2 which is not a very good solution.

Of course this change impacts current code since the imports would
have to be changed (generally not a hard code change, but a annoyance
nonetheless). Adding the subdirectories to the path would make it
work for old code (wouldn't it?). If we are going to change it, 
now's the time to consider it.

Perry