[Zope-dev] FindHomes.py

[R. David Murray]

On Thu, 26 Jul 2001, Chris Withers wrote:
> Can someoen explain lines 138 to 153 of FindHomes.py to me?
>
> Is it documented anywhere?

Don't remember reading it anywhere.  I can explain to you what the
python code is doing, but I haven't actually tried to use it, so
my explanation could have bugs (caveat emptor!):

First, it picks up the value of the PRODUCTS_PATH environment variable
(you knew that <grin>.)  Then it checks to see if that value contains
python style variable interpolations, and if so, it does the
interpolations.  This means PRODUCTS_PATH could be something like

PRODUCTS_PATH="%(PRODUCTS_PATH)s /some/other/path"

or

PRODUCTS_PATH="%(SOFTWARE_PRODUCTS)s /some/path %(INSTANCE_PRODUCTS)s"

where %(INSTANCE_PRODUCTS)s will be replaced by the path to the
Products directory in INSTANCE_HOME, %(SOFTWARE_PRODUCTS)s will be
replaced by a list containing the path to the Product directory
from SOFTWARE_HOME (Python itself sets the initial value of this
when Products is imported), and %(PRODUCTS_PATH)s is effecively a
shorthand for %(INSTANCE_PRODUCTS)s %(SOFTWARE_PRODUCTS)s, as
modified by the setting of the DISALLOW_LOCAL_PRODUCTS variable.

Once this interpolation is done (if needed), the existing
Products.__path__ list is emptied, the new products directory
list is filtered to eliminate null elements, and then each element
is checked to see if it is a directory and is added to the
Products.__path__ list if it is.

The end result of all this is that by using the PRODUCTS_PATH
environment variable, you get to influence/add to the product search
order, without having to hardcode the internal (SOFTWARE_HOME)
Products path or the path to the INSTANCE_HOME Products directory.

Note that if you use %(INSTANCE_PRODUCTS)s in your PRODUCTS_PATH
string, that this will *override* the setting of the
DISALLOW_LOCAL_PRODUCTS environment variable (ie: if INSTANCE_PRODUCTS
appears in PRODUCTS_PATH, it gets used regardless of the setting
of DISALLOW_LOCAL_PRODUCTS.)  This could be a bug, or a design
feature, and I can't decide which I think it should be <grin>.
I'm leaning toward bug, though, in which case an 'else: ip = ""'
would be an easy fix.

FindHomes.py is hotpatching the python-computed value of
Products.__path__, which is marked in the 2.0 PQR as a R/O variable,
so I'm *real* suspicious of this in design terms.  On the other
hand, the PQR also lists it as 'string/undefined', and I've checked
and it is a list in 1.5.2, 2.0, and 2.1, so maybe the PQR is also
wrong about the R/O.

(I learned something about python in writing this up: I definately did
*not* expect 'del ppath[:]' to empty Products.__path__, since I'm used
to using the [:] syntax to 'clone' (copy) a list.  On the other hand,
I did guess immediatly what the code was doing, it just surprised me
that it worked, and it surprised me that it surprised me, since I
usually find Python very consistent and intuitive.  The docs do
say that deleting a slice is "in general equivalent to assignment
of an empty slice of the right type", so I guess really it *is*
consistent...well learn something new every day...)

--RDM