Adding your own site directories cleanly and supportedly?

[Tim Bradshaw]

We have a situation where, on our production machines, we will
probably have a standard Python installation which is installed with
the system build, and which we want to use for various possible
applications. These applications will probably have different library
requirements, and may have conflicting requirements. We don't *know*
they will, but they may do and we don't want to have to worry about
it, basically.

As an example, my application uses Numeric. I suspect that no-one
else does, but I don't want to find out that they do, and they use an
incompatible version. Of course, we should really establish a
standard version and install the centrally and so on, but we probably
don't have time for that. Different versions of the application might
also need different versions of Numeric, and they need to be able to
coexist painlessly.

This looks easy to solve: Numeric uses distutils, so we can just have
per-application site directories, where applications put the things
they need with no fear of interference.

Ah, but. How do I add an application-specific site directory, and do
all the .pth file searching? It looks like I can call
site.addsitedir() to add a directory of my choosing, and this will all
work. This is all fine.

The question is: is this the right way to do this? The documentation
for site doesn't describe any functions it exports, so I'm not sure if
I'm relying on something that might change or go away at some point.
It seems to me that there *should* be a standard way of doing this,
because it must be a common need (mustn't it?): perhaps I'm missing
something, or this function should be documented?

Thanks

--tim

 

[Peter Hansen]

Ah, but. How do I add an application-specific site directory, and do
all the .pth file searching? It looks like I can call
site.addsitedir() to add a directory of my choosing, and this will all
work. This is all fine.

The question is: is this the right way to do this? The documentation
> for site doesn't describe any functions it exports, so I'm not sure if
> I'm relying on something that might change or go away at some point.

I think the comments at the top of site.py are often considered to
be the _real_ documentation for that module. Note especially this
one, at the end of those comments:

'''After these path manipulations, an attempt is made to import a module
named sitecustomize, which can perform arbitrary additional
site-specific customizations. If this import fails with an
ImportError exception, it is silently ignored.
'''

In the past, I've done what you describe by including a sitecustomize.py
in the application directory, and putting only these lines in it:

import site
site.addsitedir('.')

Then include one or more local .pth files and you're set.

Note that the code shown there works only if the current directory
is the directory where the application code resides, but that
was always the case in our code. You might need something other
than '.' if that's not the case.

-Peter

 

[David Fraser]

We have a situation where, on our production machines, we will
probably have a standard Python installation which is installed with
the system build, and which we want to use for various possible
applications. These applications will probably have different library
requirements, and may have conflicting requirements. We don't *know*
they will, but they may do and we don't want to have to worry about
it, basically.

As an example, my application uses Numeric. I suspect that no-one
else does, but I don't want to find out that they do, and they use an
incompatible version. Of course, we should really establish a
standard version and install the centrally and so on, but we probably
don't have time for that. Different versions of the application might
also need different versions of Numeric, and they need to be able to
coexist painlessly.

Aha! Another reason to use a multi-version script like we have been
talking about for wxPython. If you search the newsgroup for wxselect you
should find a script you may be able to adapt for selecting versions of
other modules...

This looks easy to solve: Numeric uses distutils, so we can just have
per-application site directories, where applications put the things
they need with no fear of interference.

We've been doing some modifications to the Numeric setup script that
make it easier to include in your application installer.