[Zope3-dev] Re: eggs in a Zope 3.3 instance

[Martijn Faassen]

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