Is there any way to make Python play well with stow?

[Tim Bradshaw]

I'd like to be able to install python with stow, and then to install
various modules which use distutils, also with stow. This currently
pretty much won't work, because Python chases symlinks to set
sys.prefix, which means that the site path gets set to the `true'
location rather than the one with all the links. This means that
Python won't find modules you install with stow, unless you glue the
linky site directory into sys.path. Doing this is OK for
applications, but it means that things like distutils break if there
are modules which depend on other modules which you've installed,
because it won't find those modules.

As an example, assume I have things appear in /local/ and the stow dir
is /local/packages/. So I build python with:

$ ./configure --prefix=/local
$ make
$ make install prefix=/local/packages/python-2.3.4

Then stow it:

$ (cd /local/packages; stow python-2.3.4)

This python's sys.path will have /local/packages in it since
sys.prefix &co have that.

Now install a module, say Numeric:

$ python setup.py install --prefix=/local/packages/numeric
$ (cd /local/packages; stow numeric)

At this point stow will have set things up so that
/local/lib/python-2.3/site-packages/ is a directory (not a link) which
contains links such as Numeric and Numeric.pth pointing to the
appropriate places under /local/packages/numeric/.

Unfortunately python will never even look for this site-packages dir
because of the link-following in the computation of sys.prefix: it
only considers /local/packages/python-2.3.4/lib/python2.3/site-packages/.
So any other module I try and install which needs Numeric will fail.

I can fix this by adding a .pth file to the `real' site packages dir
which points at the linky one, but this is something extra to do every
time I install Python: I'd really like to be able to keep the python
directory tree completely clean.

Is there anything else I can do that's not essentially equivalent to
this (so, for instance, not making the real site-packages dir be a
symlink back to the linky one...)?

I think it would be a good thing if the computation of sys.prefix did
the following: if the python binary is a symbolic link, then before
chasing the symlink, still look for things `this side' of it. If you
find something that looks like a python installation, then construct
sys.prefix &c using those paths. Only if that fails should you chase
the link and look for an installation on the far side of it. This
would allow things like stow to work transparently, I think. Of
course there may be disadvantages of doing this which I haven't
thought of.

Thanks

--tim

[Tim Bradshaw]

tf********@tfeb .org (Tim Bradshaw) wrote in message news:<fb******* *************** ****@posting.go ogle.com>...

I'd like to be able to install python with stow, and then to install
various modules which use distutils, also with stow. This currently
pretty much won't work, because Python chases symlinks to set
sys.prefix, which means that the site path gets set to the `true'
location rather than the one with all the links. This means that
Python won't find modules you install with stow, unless you glue the
linky site directory into sys.path. Doing this is OK for
applications, but it means that things like distutils break if there
are modules which depend on other modules which you've installed,
because it won't find those modules. [and so on]

About 5 minutes after posting this I discovered PYTHONHOME, which
completely stops all the intuiting sys.prefix stuff. I feel like a
fool now, and more so since posting via google means I couldn't even
point out my idiocy until today.

--tim