Hi, On Thu, 2009-04-16 at 01:01 +0200, Hanno Schlichting wrote:
Hi.
Uli Fouquet wrote:
As Grok is now approaching the 1.0 release we (i.e. some Grok developers and me) want to have a 'compliant' way to offer paster-based serving of Grok instances.
I'd love to have the same for Plone, but failed to find any canonical definition of "compliant" the same way you did.
Here's a short (probably incomplete) list of some 'full-stack' paster-capable 'frameworks' and how they invoke paster from the commandline (please correct/extend if I am wrong/incomplete here):
================ =================== ============================ Framework Ini-file location Paster call ================ =================== ============================ grokproject parts/etc/ bin/paster serve \ parts/etc/deploy.ini repoze.bfg <project root> paster serve MyProject.ini turbogears2 <project root> paster serve development.ini pylons <project root> paster serve development.ini zopeproject etc/ bin/paster serve \ etc/deploy.ini z3c.r.paster parts/<app>/ bin/app
I'll add the current Plone 4 way:
Plone parts/instance/etc bin/instance-fg
where instance-fg is a wrapper that calls:
bin/paster serve parts/instance/etc/paste.ini
Some motivators for me, as I saw some of those variants around and some input with my experience from the buildout business: - As a Unix-Lover, I do appreciate starting services having a SYSV style call, which means: (somecommand) start/stop/restart/... Thus no calls that require me to remember a config file location and pass it on. This also means that (somecommand) needs to be configurable as I might want to deploy multiple buildouts into the same machine having the deployment options create the service scripts in /etc/init.d and thus they can't all be called "instance". Having it named "myproject" seems better to me. - Also, I do like my autocomplete to leave me with full command name completions, thus: (somecommand)-ctl (somecommand)-debug doesn't work well for me: I always have to start typing again to complete the command *and* give a parameter. (Remember that I want parameters so I have SYSV compatible init commands right away) - In a buildout environment, the use of .in files breaks the flexibility that the various buildout mechanism deliver to us: extends, variable inclusion, etc. have to be built again and again and again in the recipes. We started out with zope3instance recipes that did that but finally moved away from this. - Do not make me check in generated things. - If you'd like people that know things like paster to pick up our environment easily, I think, that: make it obvious where the deploy.ini & Co went and as they are generated files, leave a visible note at the beginning of the file, that states something like: # NOTE: This file is generated by foo.recipe.paster, it will be # overwritten. Please apply changes to your buildout configuration # (located in XXX) instead of changing this file.
Another option I considered was the way zopeproject does it. Except that I still have to give a path to an "instance home" in a zope.conf file, which either needs to be filled in by buildout or otherwise '..' needs to be handled correctly for the etc/ case.
If your buildout does the right thing, then you should be able to abstract that complication away leaving only - a reference to a configuration file - maybe a working directory change Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development