Tres Seaver wrote:
> Chris Withers wrote:
>> By all means, document virtualenv as an option, but blessing it as "the
>> one true way" is a bit much...
I'm also surprised that you propose to make this *the* recommended way.
> Here's my rationale:
> - - The docs are intended primarily for folks who want to install and
> run Zope, rather than hack on it.
So you recommend virtualenv for administrators and buildout for
developers? Or where do you draw the line? And when do you recommend to
switch from one setup to the other? Or do you always recommend virtualenv?
I thought zc.buildout is preferred by most people in the Zope community.
> - - zc.buildout is *super* heavyweight compared to virtualenv
> - - zc.buildout creates an environment which is puzzling as hell for
> anybody who hasn't already drunk the koolaid ('parts'? 'eggs'?
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.
> - - virtualenv, or something damn near it, is likely to land in Python
> - - Nearly anybody else in the Python world is more likely to be
> familiar with the virtualenv stuff than with buildout.
But not everybody in the Python world is familiar with virtualenv. Why
should we encourage people to make themselves familiar with virtualenv
instead of zc.buildout?
> - - 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -