Setting up a development environment in Plone

I’ve found the learning curve for Plone to be steep. And in the beginning even the basics lead to endless unexpected results, even when following the documentation. A typical example is my attempt to follow Martin Aspeli’s book to set up a development environment.

Where Aspeli starts from a bare-bones installation, I started from the installer I downloaded from plone.org. So what I had hoped is that the develop.cfg file would be more or less the same as the development buildout.cfg that Aspeli presents in his book.

But instead, he presents a buildout.cfg which includes the development products and option, and has named the extensions to the buildout.cgf file differently. To make it worse, when at some point I decided just to use the buildout.cfg and packages.cfg from the book (I updated the versions.cfg to include the versions in the versions.cfg file from the book), a long download followed ending with an installation that would not start (Errno2: zeo.conf is missing).

If you recognize any of this: do not despair. Most of what you need to follow the examples in the subsequent chapters  is installed for you out of the box by the Plone installer, or added to the develop.cfg file that the installer adds to your installation.

Zopeskel? Already there out of the box. mr.developer? Out of the box if you run ./bin/buildout -c develop.cfg. And when you are ready to run buildout with a -c flag, then the mystery of adding products you need will have dissipated already (the chapter listing is the most comprehensive overview of tools).

It is a great book and has excellent examples to show you around. But  it is not a cookbook from which one can copy-paste at leisure into new projects. After a week I have managed to get through most of the requirements of a website I was building, and I was only able to do that by using a mix of code and tweaks through zmi.

And this required study and practice, there seems to be no other way around it. And it is true what they say: the #plone channel at irc has an incredibly helpful bunch of people behind it.

From the start I made my setup to have my development, staging and production server connected through svn. Plone buildout offers a great option to do this, by keeping a clean buildout.cfg file across the board, and change the settings for the development environment through a develop.cfg file (called on buildout by using the -c switch ./bin/buildout -c develop.cfg).

It took a while to get all the products Aspeli mentioned in the develop.cfg file, under the correct extensions. On #plone zupo helped me out with the “Error: The referenced section, ‘eggs’, was not defined” error I kept getting. Any reference to an egg which has the form: ${eggs:main} or ${eggs:devtools} is looking for a "main=" or "devtools=" property under the [eggs] section. In the example of Aspeli he has included the [eggs] set in the file packages.cfg – which in plain vanilla Plone 4.1 is not generated by the installer.

I’ve not been able to create a section eggs:main in my buildout.cfg. I’ve tried replacing the eggs= with

[eggs]
main =
plone
pillow

but this will simply not run. The same happens if I try to include a new section devtools = . Somehow these are not recognized when running buildout. So I placed the development eggs under extensions += in the develop.cfg file. And I fixed the references to the eggs with:

eggs =
${buildout:eggs}
${buildout:extensions}

because that is where the relevant eggs are found.

Setting up testing for my *.policy was another thing that took a while. But since you are seldom the only one running into a particular problem I found the solution here.

Through zmi what I used most where the portal_actions. Once you see what that can do it’s amazing, because you can set multiple actions with different conditions for any tab (tabs where my main interest), narrowing down the rights of access, and basically of anything else for specific roles. I was not able to transfer any exports I made to staging and had to rely on moving the whole Data.fs around and writing protocols to repeat in the different environments. I’m quite certain there is a way to do that neatly in code as well, but have not found it yet.

All in all, after two weeks where I was almost on the border of reconsidering my choice for Plone I’m very impressed. I do notice that things seem evident now that where very hard to wrap my mind around at the beginning. The good news is that this transition is quite quick. It’s time for me to re-read Aspeli’s book and follow his example from the ground up with the understanding I have now.