Hi there,

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.

This means mainly that when a user creates a project with `grokproject`,
we want to have the config files (deploy.ini, zope.conf, etc.) generated
in a location, that users expect. Some 'standard' location if such a
thing should exist.

This also applies to the name/functionality of the script to start the
paster server.

Currently we do it like this with `grokproject`:

Configuration files (deploy.ini, debug.ini, zope.conf, site.zcml,
zdaemon.conf) are generated by zc.buildout in a local parts/etc/
directory from templates in a project-local etc/ directory. Furthermore
we let buildout create a script ``bin/paster``, so that you can start
your instance with::

  $ bin/paster serve parts/etc/deploy.ini

Nobody seems to like this (including myself, although I am mainly to
blame for that). Especially the parts/etc/deploy.ini path is too
'hidden'. Time to learn from others.

Other frameworks (repoze.bfg, TurboGears for example) do it differently
and it looks like there is also the z3c.recipe.paster-way to do it, as
Roger Ineichen stated yesterday on this list.

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

So we have two things to decide: (1) how do we want to let people invoke
paster and (2) where do we generate the ini-files?

I guess there are pros and cons for every of the approaches and we
already discussed some of them in the Grok community, but the most
important thing is, that we would like to keep Grok compatible with
other frameworks/approaches, so that people feel a bit more used to it
when they try it for the first time.

Collected (incomplete) cons:

  - grokproject: hidden ini-file path, complicate paster invoke

  - zopeproject: supports only relative paths, one cannot invoke
         /abs/path/to/project/bin/paster serve ... from
         outside the project dir

  - z3c.recipe.paster: not sure whether commandline args like
         ``--reload`` are respected; invocation is different
         from other paster-based frameworks (this approach, however,
         looks most attractive to me).

  - turbogears2/pylons: not buildout based by default; makes it
         harder to create collaborative SVN-based projects.

At least it would be nice to have a common approach or 'best practice'
recommendation when it comes to Zope based paste deploys. It would be
even nicer to have an approach that is similar also to non-Zope
environments. We'd like to follow such a convention with `grokproject`
and learn from other's expericences in that matter.

Best regards,

-- 
Uli

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to