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