Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
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
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
On Tue, 2002-11-26 at 10:39, Jeffrey P Shell wrote: * configure; make; make install installation I thought that there was an effort to use distutils, or to at least use a distutils-ish setup. What happened to that? It does use distutils, owing to the work of Matt Behrens and Shane on the setup.py file. The configure; make stuff just wraps distutils to a large degree. I gather from reading other posts that this is a different format than Zope 3's ZCML. Would it be worth it to at least make some sort of 'ZCML Lite' to do this sort of configuration? The main thing I'm concerned about is that there's a whole new Zope coming down the road that depends heavily on configuration files, and it might make sense to start weaning people onto its general syntax if Zope 2's finally going to have a config file. As other folks mentioned, we made a conscious decision to not have an XML config file format. That said, the schema (the allowable values and sections) of the config file may be in XML and might even use ZCML (if I can figure it out). I have been paying attention to RDM's checkins to the metameta stuff on the Zope 3 branch, but I still haven't quite figured out how to use ZCML for this purpose. I've got a homebrew solution that does use XML now. Anyways - good work. The better support for Windows services alone would get you a beer if I happened to be on that coast.. :) Thanks! Cheapskate. I think you owe me at least two other beers anyway. ;-) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
CM == Chris McDonough [EMAIL PROTECTED] writes: * configure; make; make install installation I thought that there was an effort to use distutils, or to at least use a distutils-ish setup. What happened to that? CM It does use distutils, owing to the work of Matt Behrens and CM Shane on the setup.py file. The configure; make stuff just CM wraps distutils to a large degree. And configure; make; make install is a worth goal. From a sysadmin's point of view, they're already conditioned to doing this to install open source software, so under the Pinball Machine Principle, when they see one in Zope, they'll run that first before reading (the whole) README file. Low barrier of entry is a good thing! -Barry ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
I have updated this proposal to be in line with the current goals: http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration Thanks for poking me, - C On Mon, 2002-11-25 at 20:42, [EMAIL PROTECTED] wrote: Hi Could we get the Install and Configuration proposal cleaned up, with so many comments it's not clear what the actual proposal proposes to deliver now. Also parts of it's problem statement are just plain wrong. I currently have many (read every version of Zope including Alpha's and Betas since 2.4.1b1) installed on the same box, and I have 18 instances of which at least 8 are running concurrently on our dev box, currently using at least 2 different versions of Zope (2.5.1 and 2.6.0). (Some of the non running instances if I started them up would be on 2.4.3 etc.. Currently we can do everything listed as a problem in the proposal, it is clean, neat and everything is in it's place. (except maybe item 5 in the problem statement) Regards Tim On Tue, 2002-11-26 at 04:12, Brian Lloyd wrote: Is there already a schedule for Zope 2.7? (of course there is not :-) ) Now there is :) http://dev.zope.org/Wikis/DevSite/Projects/Zope2.7/FrontPage I've updated this project and tried to dispel any lingering confusion over the earlier effort labelled Zope 2.7. I proposed to include reStructuredText into Zope 2.7. This stuff is ready to be merged. If there are no objections I will merge it soon since there were only positive votes for the inclusion. Please don't merge anything until people have had a chance to see what's going on and gotten the plan finalized. Per the plan above, I'd like for there to be a (relatively short) period for people to volunteer and add proposals to the plan, followed by a process of prioritizing and coming to closure on what will / won't be included. I propose in the wiki that we should probably schedule an IRC day to do that. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) DISCLAIMER: This email, including any attachments, is intended only for use by the addressee(s) and may contain confidential and/or personal information and may also be the subject of legal privilege. Any personal information contained in this email is not to be used or disclosed for any purpose other than the purpose for which you have received it. If you are not the intended recipient, you must not disclose or use the information contained in it. In this case, please let me know by return email, delete the message permanently from your system and destroy any copies. Emails and their attachments may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems. All attachments are opened at the recipient's risk. ___ Zope-Coders mailing list [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-coders ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-Coders] Re: [Zope-dev] Moving forward with Zope 2.7
In the meantime, I think this list summarizes the adjusted goals well:
* configure; make; make install installation
* control script for starting/stopping/debugging zope
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)
* config file for all options including logging,
servers, and databases.
* real effective user support (logfiles, database files, etc.
dont get written as root if you start as root).
* better support for instance home/software home split
* 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?
* 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?
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).
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
