[Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7

[Chris McDonough]

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