On Tue, 2002-11-26 at 02:47, Guido van Rossum wrote:
I'd like to compare notes on this. Where's the control script that you are using? I'm hoping that we can use (some future evolution of) zdaemon/{zdaemon,zdctl}.py in the Zope 2.7 trunk. This separates the concerns of
- the actual server process (Zope/ZEO/ZRS; for ZEO, this is runsvr.py)
- a daemon subprocess manager, which restarts the subprocess when it dies, etc. (zdaemon.py)
- a tool to control the subprocess manager, telling it to start/restart/stop the server subprocess, etc. (zdctl.py)
This sounds like a good arrangement. Most of the code for the "ctl" app that's checked in to the chrism-install-branch is in lib/python/Controller/ZctlLib.py. A "stub" which imports this code is written out to the "bin/zctl.py" file in an instance home (after you run configure; make; make instance, for example). The pedigree of this code is that it was originally coded up by Tres but it has been hacked by me since then to support Windows and to support the loading of configuration data from a config file with "matching" command-line parameters (mostly so you can inspect the config file based environment and pass in --switches that match the names of keys in the config file). It's not a particularly pretty piece of code and I wouldn't mind at all seeing it replaced.
* better support for Windows services
I'd like to hear more about this; my zdaemon.py currently doesn't do Windows at all. Where can I peek at your code?
A file named ntservice.py is written to the bin directory of an instance home after "make instance". To install an NT service based on an instance, you would call bin/ntservice.py install. There's not much more to control when it comes to NT services. They don't seem to require any of the coding that POSIX stuff does to switch effective users or run in the background, etc. I'm not sure that you can tell an NT service to restart a process that has died, but probably. This feature is not wired up to any installer or anything, but it should be.
* RPM-building support. * where possible, the banishment of environment variables as configuration.
All of these things save for the last are more or less complete on the "chrism-install-branch" of the Zope trunk. The major missing piece is the fleshing out of the interaction between the configuration system (ZConfig) and Zope itself. It works currently but it needs to be improved and canonized to everyone's liking.
Can you point to where Zope's use of ZConfig is?
chrism-install-branch in lib/python/zope.py and lib/python/Controller/Main.py. You can sorta see it in action if you create an instance home using the instructions that come with the branch and mess around with the config file in etc/zope.conf (put bad keys and sections in there, misspell things, etc, it should give you a pretty informative message about where in the config you screwed up). The sample config file is a little misleading (actually... parts of it are just plain wrong) as it details an older generation of config file ideas. I have not had time to regenerate the default config file. The best place to get an idea of what values are available is the schema for the Zope config in lib/python/Controller/directives.xml.
Since ZConfig will also used by other ZC software (ZEO, ZRS), there's a bit of back and forth that needs to be done to get everybody to agree on a way to do it. Once that is worked out, and the proposal is cleaned up, I think we can just merge.
Apologies in advance: my refrain seems to be "where's your code for X?" -- there's so much good stuff in your branch that I don't know where to begin, especially not with the Zope part (in ZODB, I know my way around better).
It's really no problem, I realize how difficult it is to reverse engineer somebody else's head. Hopefully I can improve the proposal soon and the vision might get clearer to other folks but me. I suppose I should add "better logging support" to this list of features as well, but since we've already got it going on the trunk and we're already figuring it out, I won't. - C