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

[eric jones]

> 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?

Yes.  It is a hack IMHO also.  It trades environment variable changes to
site.py changes -- I'd rather require neither.  Still, I'd like to see
what you've done.  Can you send me that file? 
> 
> > 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.

I think now is the time to change it. 

eric