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
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 )