On Aug 28, 2007, at 5:55 PM, Ross Patterson wrote:

Putting these packages in your Zope instance home's "lib/python"
directory should get them found before the others.  For Products, you
can use an additional "products-path" directive in zope.conf and put
files in there.  I don't know how to tell buildout to do either,

But wouldn't that cause problems in this case since zope.app.interface
is a package in two nested-namespace packages.  IOW, wouldn't putting
zope/app/interface in $INSTANCE_HOME/lib/python mean that it was the
only package in the zope or zope.app namespace packages?

Gah. Yeah. Sorry. You might get away with creating and installing a custom zope.app.interface-myversion.egg into your Python's site- packages dir and using something like:

from pkg_resources import require
require('zope.app.interface = myversion')

... in a script early on or do the equivalent within a .pth file in your site-packages dir. Even after that, you *might* need to munge the PYTHONPATH, though, to prevent Zope from finding the one in SOFTWARE_HOME first. :-(

I find Ian Bicking's virtual_python.py script very useful for trying things like this out. I usually install both a custom version of Python and one or more virtual pythons in my automated scripts (using the --no-site-packages flag to virtual_python.py). This means I can let distutils/setuptools packages install to site-packages "normally" without polluting the main Python installation's site-packages and so I don't need to go through gyrations to munge the PYTHONPATH for them to be found somewhere else. I think buildout tends to prefer creating scripts that munge the path.

- C

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to