Hey Daniel,
Daniel Nouri wrote:
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.
This looks interesting.
The problem I'm facing now that I just want end users to be able to
install the Document Library and it's dependencies without any hassle.
This means that fancy setup scenarios are out of the question for the
time being - it just should work with a plain Zope 3 instance and a
plain installation of setuptools. I give you the command and the
Document Library deploys. And I'm about 3 lines of code away from that
scenario...
I think that we should definitely look into various approaching
concerning this whole story leading up to Zope 3.4 however.
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.)
That's a good point. lib/python in a Zope 3 instance is however not
something you can just import things from anyway - you'd have to set up
a PYTHONPATH that includes Zope 3 itself at the very least. That said,
making it a site makes this one bit more difficult, *if* at least you've
got eggs installed into lib/python...
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.
As Jim mentioned in his mail concerning zc.buildout, it appears he's
working on a way to work with setuptools that completely sidesteps the
need to make things a site and relying on setuptools in application
code. If this can be made to work well then that might in the end be a
simpler approach for setuptools as a whole.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
