Jeff Kowalczyk wrote:
Philipp von Weitershausen wrote:
Is there a pro/con list to including a in zopeproject for the
other way of using buildout?
I don't quite understand. zopeproject works completely without needing After calling zopeproject, you end up with a completely bootstrapped *and* installed buildout sandbox.

This non-system python-2.4.4 has an empty site-packages, and is
owned by root. I don't have setuptools or buildout installed in the
non-system python.

When working with a z3c.formdemo checkout for example, I can start:

# /opt/python24/python/bin/python
Without using sudo. That bootstrap process creates a local bin/buildout,
uses setuptools and zc.buildout from ~/.buildout/eggs, and the non-system

Yes, I'm quite familiar with It's from a completely different use case, though. With z3c.formdemo, you checkout an existing buildout directory, bootstrap it and then execute the buildout.

With zopeproject, you actually have a tool that creates all that buildout boilerplate for you, then automatically bootstraps the buildout and executes it. zopeproject is a tool. For that to work, zopeproject needs to be installed first. Before any of the buildout stuff happens. So you're going to have to easy_install it somehow. If you'd rather not, that's fine. But then you don't get to use that tool.

I'm going to familiarize myself with virtualenv; I haven't yet only
because the above method seemed both convenient and clear about its use of
python environment and eggs.

I'm not sure what there is to familiarize with. I pretty much spelled it out for you how to use virtualenv. From an earlier email ( is from the virtualenv tarball):

 $ python env
 $ cd env
 $ bin/easy_install zopeproject
 $ bin/zopeproject HelloWorld

This should be easy enough to try out in 2 minutes, probably less time than it took you and me to write these emails.

-- -- Professional Zope documentation and training

Zope3-users mailing list

Reply via email to