[Zope3-dev] Re: eggs in a Zope 3.3 instance
Jim Fulton wrote: Concretely, what do you think about making lib/python in a Zope 3.3 instance a site for now (calling site.addsitedir())? I think it's a bad idea, mainly because it's too late to make such a change for 3.3. I tell you what I will do though, I'll promise, by the end of EP, to have a buildout that lets you define Zope 3.3 instances with the eggs of your choice. That sounds very interesting. However, zc.buildout is clearly aimed at large deployment. A *simple* way of deploying eggs in instances would still be needed (*I* need it, in fact); if not in Zope 3.3, then at least later. Currently you only have to drop package directories into INSTANCE/lib/python, something similar with eggs should also be possible. I frequently get lost between sys.path, sys.prefix, .pth files and the site.py module. The fact that a one line fix gets what we want seems simple enough to me. As said, I'm not the expert here, though :) Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggs in a Zope 3.3 instance
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 Regards, Daniel ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: eggs in a Zope 3.3 instance
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
