Hi Martijn!

I forgot to mention workingenv[1] yesterday on IRC.  It's much easier
than using virtual-python.py.  Using workingenv means you can just
"easy_install yourproject" without any further arguments.  Of course you
have to take care that the environment is active when you run the Zope
instance.  I *think* that testrunner should work with that setup.

I can think of one downside of making lib/python a site: It's magical
and it doesn't allow you to just start up the interpreter and try things
out.  "Site-wide" installations where the instance is agnostic of
PYTHONPATH et al allow that.  (Where site-wide only means that the
instance doesn't care.)

Of course that can be fixed by providing something like workingenv's
'activate' for the Zope instance; maybe that's a feasible way:  You
activate and then you can install and run?

Side note: I think it would be nice to have a zcml equivalent to
pkg_resources.require() so that Zope can natively work with
"--multi-version"[2] setups.  This would mean that different Zope
instances can use different versions of installed packages, which I
believe is partly the motivation for having a lib/python per instance.

[1] http://blog.ianbicking.org/workingenv-revisited.html
[2] http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to