[Zope-dev] Best way to invoke paster/WSGI apps on cmdline

[Christian Theune]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090418/f6c1c81b/attachment.bin