[Zope-CMF] Re: Tools as local utilities

[Martin Aspeli]

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 
may work.

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
  $ bin/buildout

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 
buildout.cfg.

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.

Martin