Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Uli Fouquet wrote: > Very interesting. Thank you very much, Roger! Right now I have some > problems with zdaemon as told in my reply to Christian. But if everybody > likes it, also Grok/grokproject will go that way :) Hhm, for Plone 4 I was so far considering to not use zdaemon at all anymore. Both mod_wsgi and supervisord should be able to handle the multiple process case, so we can get out of this business. Hanno ___ 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 )
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Hi there, Am Sonntag, den 19.04.2009, 09:33 +0200 schrieb Roger Ineichen: > > > Betreff: Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline > > > > Hi there, > > > > Christian Theune wrote: > > > > > On Thu, 2009-04-16 at 01:01 +0200, Hanno Schlichting wrote: > > > > Hi. > > > > Sorry Hanno, your posting got lost on the way to my > > mailreader. I noticed you replied when reading Theuni's posting. > > > > > > 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. > > > > Glad to hear that others have the same problems :) > > > > > > > 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 locationPaster call > > > > > === > > > > > > > grokproject parts/etc/ bin/paster serve \ > > > > > parts/etc/deploy.ini > > > > > repoze.bfg paster serve MyProject.ini > > > > > turbogears2paster serve > > development.ini > > > > > pylons paster serve > > development.ini > > > > > zopeproject etc/bin/paster serve \ > > > > > etc/deploy.ini > > > > > z3c.r.paster parts//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 > > > > We thought about this as well. > > > > > 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. > > > > I see. I am not sure, everybody has this requirement, but we > > should keep it in mind. The question here is: how do you name > > your commands then? Do you opt for (somecommand) --debug or > > similar in that case? > > > > > - 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. > > > > Interesting. This, at least with Grok, can become a serious > > problem. We currently have five different configuration
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Hi there, Christian Theune wrote: the cited response from Christian did not make it to the list as I didn't reply to all in my first reply. Sorry! > On Sat, 2009-04-18 at 19:25 +0200, Uli Fouquet wrote: > > We thought about this as well. > > > > > 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. > > > > Okay, that should be easy with buildout. > > > > > - 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) > > > > I see. I am not sure, everybody has this requirement, but we should keep > > it in mind. The question here is: how do you name your commands then? Do > > you opt for (somecommand) --debug or similar in that case? > > I consider failing tab-completion to be an indicator of something being > wrong. ;) > > The --debug is an interesting case here. Used to zdaemon, I merely use the > commands > to specify what to do with the (completely) configured service: > > - start it > - stop it > - restart it > - reload it > - ... > > Starting a daemon in --debug mode usually involves manually touching a > configuration > file - which would definitively be a hassle if you switch back and forth. Why does it involve touching the configuration? > OTOH Zope has a "debug mode" parameter which you set globally for your server > (in the zope.conf) to get debug functionality and then just start the server > regularly. The one option we do differently from normal init scripts with > zdaemon > is the `fg` command which supports the debug/development scenario. Yes, that's the Zope way. With paster, however, starting in debug mode means using a different .ini file. And it is not limited to debugging. There can be different setups for different purposes with different WSGI pipelines. The Zope "debug mode" parameter cannot easily be injected into this pipeline, at least as long as the publisher does not set an appropriate pipeline variable. This might change with Shanes new publisher implementation but currently "debug mode" means different things with paster and with Zope. I'd simply like to open that up for approaches the paster community is used to. > > > - 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. > > > > Interesting. This, at least with Grok, can become a serious problem. We > > currently have five different configuration files generated by > > `grokproject`. Admitted, that one might skip one (`debug.ini`), we are > > left with four, which require three different configuration grammars: > > > > zope.conf, zdaemon.conf: ZConf grammar > > deploy.ini: ConfigParser grammar > > site.zcml: ZCML > > > > but this is a different topic. > > I'm not saying you shouldn't generete .ini files, but you should > avoid .in files. You can't avoid .ini files with paster (AFAIK). The problem here is to read and edit those files, not to generate them :) In the beginning I was very confused when I looked at buildout.cfgs with embedded site.zcml and zope.conf and thought that there was no other way until I realized that they were files-in-files. But maybe others can cope better with that right from the beginning. > > Some of those files (namely the .ini files) meanwhile have grown large > > defining loggers and all that. Putting them into buildout.cfg makes it > > nearly unreadable. It becomes even difficult to check, which part of the > > configuration you're currently watching. People with more advanced > > setups might run into even greater trouble. > > > > So, the pros and cons of external vs. buildout.cfg-embedded config files > > might read like this (for embedded configs): > > > > * pros: > > > > - supports all buildout mechanisms > > (namely: var interpolation and extend) > > > > - all configs in one file (you know where to look for them) >
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Hi all > Betreff: Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline > > Hi there, > > Christian Theune wrote: > > > On Thu, 2009-04-16 at 01:01 +0200, Hanno Schlichting wrote: > > > Hi. > > Sorry Hanno, your posting got lost on the way to my > mailreader. I noticed you replied when reading Theuni's posting. > > > > 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. > > Glad to hear that others have the same problems :) > > > > > 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 locationPaster call > > > > === > > > > > grokproject parts/etc/ bin/paster serve \ > > > > parts/etc/deploy.ini > > > > repoze.bfg paster serve MyProject.ini > > > > turbogears2paster serve > development.ini > > > > pylons paster serve > development.ini > > > > zopeproject etc/bin/paster serve \ > > > > etc/deploy.ini > > > > z3c.r.paster parts//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 > > We thought about this as well. > > > 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. > > I see. I am not sure, everybody has this requirement, but we > should keep it in mind. The question here is: how do you name > your commands then? Do you opt for (somecommand) --debug or > similar in that case? > > > - 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. > > Interesting. This, at least with Grok, can become a serious > problem. We currently have five different configuration files > generated by `grokproject`. Admitted, that one might skip one > (`debug.ini`), we are left with four, which require three > different configuration grammars: > > zope.conf, zdaemon.conf: ZConf grammar > deploy.ini: ConfigParser grammar > site.zcml: ZCML > > but this is a different topic. > > Some of those files (namely the .ini files) meanwhile have > grown large defining loggers and all that. Putting them into > buildout.cfg makes it nearly unreadable. It becomes even > difficult t
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
Hi there, Christian Theune wrote: > On Thu, 2009-04-16 at 01:01 +0200, Hanno Schlichting wrote: > > Hi. Sorry Hanno, your posting got lost on the way to my mailreader. I noticed you replied when reading Theuni's posting. > > 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. Glad to hear that others have the same problems :) > > > 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 locationPaster call > > > === > > > grokproject parts/etc/ bin/paster serve \ > > > parts/etc/deploy.ini > > > repoze.bfg paster serve MyProject.ini > > > turbogears2paster serve development.ini > > > pylons paster serve development.ini > > > zopeproject etc/bin/paster serve \ > > > etc/deploy.ini > > > z3c.r.paster parts//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 We thought about this as well. > 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. I see. I am not sure, everybody has this requirement, but we should keep it in mind. The question here is: how do you name your commands then? Do you opt for (somecommand) --debug or similar in that case? > - 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. Interesting. This, at least with Grok, can become a serious problem. We currently have five different configuration files generated by `grokproject`. Admitted, that one might skip one (`debug.ini`), we are left with four, which require three different configuration grammars: zope.conf, zdaemon.conf: ZConf grammar deploy.ini: ConfigParser grammar site.zcml: ZCML but this is a different topic. Some of those files (namely the .ini files) meanwhile have grown large defining loggers and all that. Putting them into buildout.cfg makes it nearly unreadable. It becomes even difficult to check, which part of the configuration you're currently watching. People with more advanced setups might run into even greater trouble. So, the pros and cons of external vs. buildout.cfg-embedded config files might read like this (for embedded configs): * pros: - supports all buildout mechanisms (namely: var interpolation and extend) - all configs in one file (you know where to look for them) * cons: - harder to read - confusing syntax (mix of at least three grammars) - impossible to split permissions on parts of the config With external configs it's the opposite picture. Can you tell more about the problems with zope3instance? > - Do not make me check in generated things. Of course. As with buildout we _will_ have generated files (opposite to most other frameworks). This means that we cannot put flat ini files in the project/instance root (as they won't be flat files but generated ones). > - 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 we
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
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 locationPaster call > > === > > grokproject parts/etc/ bin/paster serve \ > > parts/etc/deploy.ini > > repoze.bfg paster serve MyProject.ini > > turbogears2paster serve development.ini > > pylons paster serve development.ini > > zopeproject etc/bin/paster serve \ > > etc/deploy.ini > > z3c.r.paster parts//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 · c...@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 signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] Best way to invoke paster/WSGI apps on cmdline
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 locationPaster call > === > grokproject parts/etc/ bin/paster serve \ > parts/etc/deploy.ini > repoze.bfg paster serve MyProject.ini > turbogears2paster serve development.ini > pylons paster serve development.ini > zopeproject etc/bin/paster serve \ > etc/deploy.ini > z3c.r.paster parts//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 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. > 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. My conclusion on this so far is: it's a matter of taste for the most part and there doesn't seem to be any good convincing argument for any of the variants. The way I choose it for Plone 4 right now is basically to minimize the difference to the former invocations. The main reason for the former state of affairs is however to support multiple ZEO clients inside the same buildout. I'm not sure if this use-case exists for Paste or if multiple processes are usually handled by using some form of mod_wsgi anyways. Hanno ___ 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 )
[Zope-dev] Best way to invoke paster/WSGI apps on cmdline
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 locationPaster call === grokproject parts/etc/ bin/paster serve \ parts/etc/deploy.ini repoze.bfg paster serve MyProject.ini turbogears2paster serve development.ini pylons paster serve development.ini zopeproject etc/bin/paster serve \ etc/deploy.ini z3c.r.paster parts//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 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 )
