[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