[Zope3-Users] Attn Jim Fulton: Buildout builder

David Pratt fairwinds at eastlink.ca
Sat Mar 15 09:48:59 EDT 2008


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?

Regards,
David


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
> 
> -- 
> Jim Fulton
> Zope Corporation
> 
> 
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
> 


More information about the Zope3-users mailing list