[Grok-dev] Re: an application installation script?

Philipp von Weitershausen philipp at weitershausen.de
Fri Oct 5 05:39:16 EDT 2007

Martijn Faassen wrote:
> For development the case seems less strong. We've heard Philipp report 
> that this is confusing for beginners. I hadn't noticed this in the Grok 
> tutorial I gave and others don't seem to have noticed this either.

Maybe I didn't explain it well enough. But then again, I'm not the only 
one who's made this experience. Brandon has reported the same a few 
weeks ago. Shane too.

> One feature that is currently missing is the way to configure a 
> particular application to act as the 'root', so that no further virtual 
> hosting configuration is needed. This feature would be useful during 
> deployment in particular.
> This feature could be triggered from the Grok UI, but that won't help in 
> some deployment scenarios.
> So let's sketch out a design:
> * the ZODB knows which applications are installed
> * the ZODB can be configured to make one application the traversal root.
> * there is a UI to configure this. For deployment, it should be possible 
> not to install the UI.
> * there is also a command-line tool to configure this. This can be used 
> to talk to Grok (perhaps by using XML-RPC or REST, or perhaps by 
> mounting the ZODB directly) and set up applications and the root, or 
> also to remove applications or 'de-root' the root.
> The deployment installation scenario would be:
> * run buildout
> * a tool has been generated in 'bin'. Doing "bin/groksetup foo" or 
> whatever would set up application "foo" as the default root. (details to 
> be worked out. This is a command-line UI issue).
> * we could research whether this tool could be made to run as the last 
> buildout step (and what would happen if you ran buildout multiple times).
> There is some benefit to letting such installation be an explicit step. 
> I think this would be okay for sysadmins. It might be a problem if this 
> is also for newbies.

I would prefer if

* the grok.Application subclass were the root object by default, without 
having to do an extra step (when I start out, there's usually just one 
application anyay). Flexibility is nice, but Grok is all about making 
sensible choices for you, at least in the beginning.

* the choices of which root object was installed was somehow tied to the 
application startup process, "applictaion" referring to the WSGI 
application. I think it should be a choice of the WSGI app factory. This 
is much like other web frameworks deal with choosing "the application" too.

I've outlined what it could look like in a reply to JW.

http://worldcookery.com -- Professional Zope documentation and training

More information about the Grok-dev mailing list