Am 03.03.2010, 21:27 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:
I recommend virtualenv to anybody who just wants to install and run the Zope2 appserver, without needing to drink a lot of "kool-aid": just install it from PyPI, run 'mkzopeinstance', and you're done. Note that I specifically remomve the non-virtualenv easy_install docs: I don't want us *ever* to encourage the use of easy_install outside a virtualenv.
Thanks for the clarification.
I thought zc.buildout is preferred by most people in the Zope community. buildout works for *developers*: it is completely strange for people who just want to install and run Zope. Mixing the buildout version of the installation in with the non-buildout version was a disaster, from a readability standpoint.
I'm not sure if take up outside the Zope community is that important. I've not come across virtualenv in a non-Zope context but then I don't spend a lot of time trying out all the "cool" software out there. What is important is that people can get up and running easily and don't f*ck their systems with injudicious use of setuptools magic. The important thing, as I see it, is: "In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it." In my view neither virtualenv nor buildout are quite there. If someone can explain to me how to use virtualenv in a way that makes it easy to deploy what I've developed on another environment then I'd be happy to go that way.
virtualenv is also puzzling if you are not familiar with it. Using activate and deactivate or the right paths isn't much easier to learn than using zc.buildout.
The environment itself is much closer to what people expect: libraries installed under 'lib/pythonX.Y', scripts in 'bin', headers in 'include', no funky 'parts' or 'eggs' directories, no idea that config files might get blown away just because you update software. I know that some of that is due to popular recipes, but that argument is specious: buildout's value proposition derives in part from the network effect of having those recipes available and widely used.
The layout of a buildout project is indeed somewhat confusing. But the config file makes it much easier to replicate what you're doing elsewhere and I think most Zope users will be developing something locally to run elsewhere, in which case it should be made as easy as possible to replicate the experience. The only install & run users I can think of would be Plonies and they have their unified installers anyway.
Activate is a completely unnecessary attractive nuisacne: I *never* use it, and I routinely see people who *do* use it end up running from different environments than the ones they think they are running.
+10 I thought I'd been dumped into a new shell / interactive Python the first time I saw it!
- - We have two alternate zc.buildout scenarios (install Zope + run mkzopeinstance vs. self-contained environment). The first has no real advantage over the virtualenv one, except being able to run buildout to update the software (heaven help you if you forget to configure the index properly!). The second leaves you without the annotated config file, a *major* faux pas.
I consider the self-contained scenario still as experimental. Following the instructions requires much more typing than the other scenarios. But I'm optimistic it can and will be improved. The self-contained mode is likely *perfect* for developers who produce a highly-customized bundle o Zope, 3rd party software, and custom code. It just isn't right as the "first choice" for somebody installing Zope for the first time.
Who is likely to be installing Zope for the first time? Much as I love Zope, we have to acknowledge that as things stand Zope is not attractive for newbies. But this is not just about getting up and running. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226