[Zope-CMF] Re: Tools as local utilities
optilude at gmx.net
Tue Feb 6 19:30:59 EST 2007
Jens Vagelpohl wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 7 Feb 2007, at 00:36, Martin Aspeli wrote:
>> Eggs make your life easier, especially if you want to use tools
>> like workingenv.py or zc.buildout.
> Well, for simple work with the CMF like setting up a quick instance
> for hacking and development *I do not want to use any tools*. I want
> to retain the same ease I currently have where all I need to do is
> either copy or link a few directories into the instance Products
> folder. It's intuitive and very fast for a Zope 2 developer. If you
> can offer the same ease and speed with a different approach, fine.
> But I don't see it with those wondrous tools.
For Plone 3 development, we have two solutions (depending on which one
you prefer). I'll explain them briefly to give you a flavour of how they
The first is called ploneout, and is a zc.buildout. We had to create a
couple of recipes to play nice with Zope 2, but these would work fine
with CMF. Basically, all ploneout is, is a particular buildout.cfg that
references Plone's eggs and products via svn:externals, in "development
mode" (as opposed to as dependencies). This also downloads builds Zope
2.10 and all other dependencies, in a single command (though if you want
to point to an existing Zope install to save space, you can).
$ svn co https://svn.plone.org/svn/plone/ploneout/trunk plone3
$ cd plone3
$ python boostrap.py # only needed once
$ bin/buildout # needed each time you change buildout.cfg
$ bin/instance fg # start zope
What's nice is that we can point new developers at this and they have a
fully replicable environment for "proper" development on Plone 3 itself.
The plone eggs are in src/ and products in products/, via svn:externals,
so you can work on them and then commit changes.
If you were using this for your own project and you wanted to Plone, CMF
and all the eggs only as a dependency, maybe with your own eggs and
products in development mode, you can create a buildout.cfg by answering
a couple of questions (or accepting the defaults) from paster.
$ easy_install ZopeSkel # gets Zope/Plone templates for paster
$ paster create -t plone3_buildout myproject
$ cd myproject
$ python bootstrap.py
The buildout.cfg file contains a list of the eggs you want, and you tend
to put development eggs for your project in src/ and reference them in
Daniel Nouri has a slightly different approach, using workingenv.py.
Whereas buildout.cfg is a single-file configuration for the eggs,
downloads and other build steps you want in your environment, his
"ploneenv" approach creates a more traditional Zope instance. It's more
for projects using Plone as dependency again, because it basically
installs the Plone egg, which in turn keeps track of all the various
eggs we have as dependencies and all the products. There could be a CMF
meta-egg that'd work similarly.
$ easy_install ploneenv
$ ploneenv -m /path/to/zope/utilities/mkzopeinstance.py myproject
$ bin/zopectl fg # as usual
The workingenv approach lets you install eggs into it, not interfering
with global site-packages, using the local bin/easy_install. If you
prefer, you can "source bin/activate" and it'll set your PATH and
PYTHONPATH as necessary so that your shell is always in the "local"
environment. "decativate" (or quitting your shell) turns that off again.
More information about the Zope-CMF