Am 03.03.2010, 21:27 Uhr, schrieb Tres Seaver <tsea...@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
>> 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.
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.
Clark Consulting & Research
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -