[Zope-dev] [Zope-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.

[Charlie Clark]

Am 03.03.2010, 21:27 Uhr, schrieb Tres Seaver <tseaver at 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