Hi Malthe. I tend to agree. Anyone that can write python can create a recipe of any kind for whatever purpose. Most concrete recipes already exist for the fairly standard things one needs to do. At the very least, they can be emulated by someone new to buildout. There is little daunting about constructing a text file to create a buildout. Reading Jim's excellent tutorial and understanding how it works and extending for your needs is fairly explanatory.

Perhaps I am missing the point of the project, but a gui may be more difficult to maintain than it is worth. Each recipe has its own options that must be validated. The fact that they are options means they can be used/not used in most cases. Even then, one would still be faced with key/value pairs that would involve entering text or turning options on or off. I am assuming that the next step would be generating documentation to use the gui explaining the options that can be chosen and possible values and consequences for each recipe. So not really sure what this accomplishes myself.

I guess I would also ask what audience are the project is intended to serve. Either you are a developer and are concerned of the details of the software or an implementer/user that knows less or perhaps nothing? If the second is what the project is aiming at, then perhaps this is better accomplished with traditional installers and packaging tools with better documentation about the specific application (plone for example).

I tend to see more suggestions that seem to have the objective of removing the developer from an understanding of what they are working with. If there is a high level of redundancy, or a need to assist/reduce the tedious or mundane, then it is reasonable to consider tools. Other than that, why a tool would be used by someone that would not understand or interpret its output as you have pointed out. The text of a buildout can be assembled fairly quickly when you know what you are doing since most common things you need to do are available. Perhaps the recipes could be communicated better, but then is this not what we have pypi for?


Jim Fulton wrote:
I replied to this privately. This has gotten so much discussion, I think I'd better clarify my position.

On Mar 14, 2008, at 8:27 AM, Derek Richardson wrote:

I am the Plone champion for the buildout builder. The buildout builder will be a web application, likely written in Grok, that will allow textually-challenged users to configure a buildout via a GUI and receive a .cfg in return.

Jim, you mentioned at PSPS-2008 that you would gladly help whoever championed this.

There was a misunderstanding or miscommunication.

I volunteered to help with a buildout-based installer. This is *much* narrower than a buildout-building GUI. My thought was that, for a simple installer, there could be GUI that asked the user some high-level configuration questions and then ran a buildout included with the software to set up instances. This is similar to what we're doing for deployments at ZC where we have high-level non-buildout configuration files that collect options that control instance installs. The instance installs are actually done by running buildouts.

I have about as much interest in a GUI to help me write buildout configurations as I have in a GUI to help me write Python scripts. :)

I do see potential benefits of having GUIs or other automation tools to help people get started assuming that the scope of these tools is very narrow. They are only either to help people get started or for people who's needs will never be anything but simple.


Jim Fulton
Zope Corporation

Zope3-users mailing list

Zope3-users mailing list

Reply via email to