[Zope-Checkins] CVS: Zope - DELTAS.txt:1.1.2.1 TODO.txt:1.1.2.19
Chris McDonough
chrism@zope.com
Tue, 28 Jan 2003 22:21:41 -0500
Update of /cvs-repository/Zope
In directory cvs.zope.org:/tmp/cvs-serv29004
Modified Files:
Tag: chrism-install-branch
TODO.txt
Added Files:
Tag: chrism-install-branch
DELTAS.txt
Log Message:
Prioritized and updated TODO.
Broke out "deltas" section of TODO into DELTAS.txt.
=== Added File Zope/DELTAS.txt ===
MAJOR DELTAS TO TRUNK IN THIS BRANCH
------------------------------------
- wo_pcgi, w_pcgi, z2.py are gone.
- lib/python/zope.py is "moral equivalent"
of old z2.py
- Zope now doesn't by default need to be
run from build directory. "make install"
creates a distribution dir.
- instance_home setup is now default
by way of "./configure; make; make install;
$prefix/bin/mkzopeinst.py".
- starting and stopping zope now typically
performed via "zctl".
- ZLogger package retired.
- config file placed in instance_home /etc
directory.
- inst directory is completely changed and
contains skeleton directories for both
"make install" and "make instance" as
well as other utility programs.
- setup.py has moved into inst directory
and has been changed to deal with branch
new packages, package moves, and deals
better with Windows builds.
- "make rpmdist" makes a Zope RPM distro.
- "make testinst" makes the build dir into
both a software home and an instance_home.
=== Zope/TODO.txt 1.1.2.18 => 1.1.2.19 ===
--- Zope/TODO.txt:1.1.2.18 Tue Jan 28 14:49:04 2003
+++ Zope/TODO.txt Tue Jan 28 22:21:38 2003
@@ -1,5 +1,21 @@
-TODO
-----
+The following is a TODO list dealing with installation and startup
+changes proposed for the Zope trunk. It is prioritized into five categories:
+
+ "TODO BEFORE MERGE" (items to do before the chrism-install-branch,
+ upon which most of these changes are now being made, can be merged
+ into the Zope trunk)
+
+ "BEFORE RELEASE OF ZOPE 2.7A" (items to do before the first alpha
+ release of Zope 2.7)
+
+ "MAYBE NEVER BUT NICE TO HAVE" (items that are not on any critical
+ path)
+
+ "DONE" (items that have been done).
+
+-------------------------
+ TODO FOR MERGE
+-------------------------
Critical review of config file schema
@@ -57,43 +73,33 @@
purpose for the branch, and should not be considered together with
the rest of the branch. I.e., this task should be dropped.
-"zctl" should have a "logtail" option
-
- It should be possible to tail the event, trace, and access logs
- using zctl (in a cross-platform way).
-
- XXX This should be acquired from the new zdctl.py, and should be
- considered separately from the rest of the changes on this branch.
-
-Zope.Startup.ZCtlLib needs refactoring
-
- Zope.Startup.ZctlLib (zctl's backend) is ugly and could use some
- refactoring, and possibly a whole new approach to "ctl" should be
- considered. Maybe instead of spawning a separate process, use a
- strategy like Guido's runzeo.py, which actually constitutes a
- mainloop.
-
-Default logging destinations
-
- If logging parameters are unspecified in the configuration, the
- default is to log zLOG messages to CLIENT_HOME/event.log and to log
- access messages to CLIENT_HOME/access.log. This differs from older
- branches inasmuch as log messages in default mode (aside from
- startup messages) will no longer be written to stdout.
- STUPID_LOG_FILE and friends no longer have any effect.
-
- This is also why logtail is a desirable option (to give back this
- useful feature).
-
- This change needs to be communicated in docs and to developers in
- some way.
-
-"configure" shell scripts need peer review
-
- I'd like someone to review the "configure" and "configure.bat"
- scripts in the top-level directory and suggest/make changes. These
- scripts help find a suitable Python interpreter and create a
- Makefile on UNIX and Windows, respectively.
+ AAA It has very few changes. But its placement is a mess that I
+ think we have an opportunity to fix with the merge, and moving
+ it makes the installation and startup code simpler.
+
+ That said, if we don't move it, the branch's inst/setup.py needs
+ to be changed to install it from its mistaken place during "make
+ install" and we need to figure out what the best way to run Zope
+ from the build directory is (do we copy ZServer to lib/python in
+ a make step or do we add the ZOPE_HOME to sys.path?)
+
+Replace ZCtlLib/zopectl with zdctl variant
+
+ Replace the current ZCtlLib/zopectl stuff with a variant of Guido's
+ zdctl/runsrvr system, which we might call "zopectl".
+
+ Issues:
+
+ - I dont think we need a config file for zopectl. We should give
+ it sensible hardcoded defaults instead, and it should probably
+ be capable of reading the Zope config file to find out the
+ things it needs to know (logfile placement comes to mind).
+
+ - zdctl/runsrvr doesn't do Windows. It would be nice to have a
+ zopectl on Windows but not strictly necessary. If there is no
+ zopectl on Windows, we will need to spell this out in the docs.
+ We will also need the ntservice.py module to issue different
+ commands to start and stop the service.
"utilities" top-level directory should be renamed "bin"
@@ -122,53 +128,8 @@
"overrides" or "getSchemaKeys" is likely aiming to deal with this),
but none of it actually works.
-Find a place for zLOG.DebugLogger and zLOG.AccessLogger
-
- These packages are placed here because I've got no better place for
- them. They really don't belong here, as they are the loggers for
- "detailed" request logging and access logging respectively (not
- event logging, which is really zLOG's only domain).
-
-Zope.Startup.nt.NTService.py and instance_home/bin/ntservice.py need
-testing
-
- These modules allow you to associate an NT service with a Zope
- instance_home. Success means being able to invoke the ntservice.py
- module to create an NT service which can successfully start and stop
- a Zope instance on a per-instance-home basis.
-
- Update: As of Jan. 13, this fails -- instance-home-based services
- report failure on start (even though they start) and cannot be
- stopped.
-
-win32-eventlog needs testing
-
- The "win32-eventlog" log handler (which is creatable via the config
- file) needs to be tested.
-
-Deal with lack of PCGI
-
- In the old setup style, "w_pcgi.py" was invoked to install Zope with
- a PCGI ("persistent CGI") socket and files necessary for using Zope
- in conjunction with Apache/IIS. There are no knobs for installation
- right now to do the same thing. The 'pcgi' directory still exists
- in the Zope root dir and the 'make_resource.py' file in "inst" also
- is available, in case we decide to do something with them.
-
-Update Zope distribution creation machinery
-
- The current distribution-creation machinery will almost certainly
- fail if it's not updated with knowledge of the new Zope installation
- regime.
-
-Get rid of ZOPE_HOME
-
- An environment variable named ZOPE_HOME was added in 2.6. This
- envvar is not necessary if ZServer is moved into lib/python. It's
- usage is cruft and should be exorcised.
-
- The config schema currently uses a zope_home key. This key and its
- associated schema handler should go away as well.
+ XXX This was done somewhat via a cmdline.py module in Zope/Startup
+ but needs to be replaced with zdoptions.
Write some unit tests
@@ -183,25 +144,6 @@
exception handler which needs to do sane things to distinguish
between configuration errors, true system exit, and unknown errors.
-RPM install should recompile .pycs
-
- The RPM spec file (inst/Zope.spec.in) should delete and recompile
- .pycs/.pyos during an RPM install to make sure tracebacks contain
- real Zope filenames instead of filenames relative to the build
- directory. Alternately the RPM install should not contain .pycs or
- .pyos.
-
- XXX Not clear why this is actually needed; importing a module causes
- the __file__ to be updated with the right filename. A nice touch,
- but not required.
-
-RPM install versioning scheme needs to be documented
-
- The RPM builder has a versioning scheme via the generated Makefile
- in order to allow for the install of multiple simultaneous versions
- of Zope on a single system. This versioning scheme should be
- documented.
-
Config file needs better inline docs
The Zope zconfig config file has some inline docs. They need to be
@@ -214,16 +156,6 @@
Make sure zope.py, zctl.py, and ZctlLib.py have sane help output
(make sure it matches the capabilities of the system).
-ZConfig defaults
-
- We deferred several issues that we recognized as areas for
- improvement in ZConfig that might make it possible to avoid writing
- nasty procedural code for default handling unnecessary
- (e.g. Zope.Startup.handlers._RootHandler). See
- http://my.zope.com/CPM/CPM/issues/4 and
- http://my.zope.com/CPM/CPM/issues/3. Not necessary for merge, but
- useful to think about for future.
-
DBTab Integration
The Zope config file currently allows you to specify multiple
@@ -276,19 +208,6 @@
disk (maybe via unit tests) before Zope has had a chance to switch
effective users.
-Logging during startup
-
- The branch takes the strategy of logging to stdout and buffering log
- messages until "real" loggers can safely be configured. After
- "real" loggers are configured, the log messages buffered at startup
- are flushed to the "real" loggers.
-
-Server construction errors need to be better
-
- When a server is constructed, it attempts to bind to a port. If the
- port cannot be bound, an error is raised. The error currently doesn't
- include the port number, and should.
-
Performing the merge
I am not at all confident that doing a cvs up -j
@@ -316,25 +235,12 @@
XXX What is actually needed to verify that it isn't needed?
-Beautify output of "make" and "make install".
-
- The output of make and make install is ugly.
-
-What to do about envvars?
-
- Envvars are still used "under the hood" in ZConfig handlers as the
- result of particular configuration declarations in order to make
- Zope do the right thing (e.g. INSTANCE_HOME, SOFTWARE_HOME,
- DTML_REQUEST_AUTOQUOTE, SESSION_TIMEOUT_MINUTES and other envvars
- are set in ZConfig handlers for their respective keys). But envvars
- should not be used to try to configure Zope, as the handlers
- overwrite existing envvars with prejudice. We need to come down on
- one side or the other about envvars.. either they should be
- respected at startup as they always have been or they should be
- explicitly not respected. Currently they are not respected.
-
- We need to communicate this decision to developers and update
- doc/ENVIRONMENT.txt as necessary.
+ AAA THe best way to do this is to write a unit test which verifies
+ that the default objects installed into a "new" ZODB when Zope
+ starts are present and working, and their content either matches
+ the content of what would have come from Data.fs.in or is "close
+ enough". The code that installs these default objects exists in
+ the initialize function within lib/python/OFS/Application.
App.FindHomes should be changed to defer to configuration instead
of guessing about HOME locations
@@ -365,13 +271,165 @@
Duh.
-Create a Zope 2.7 Install HowTo on Zope.org.
+Review the Zope Book 2.6 Edition chapters and come up with revisions
+or at least create a Zope Trunk Install HowTo
+
+ The 2.6 edition Zope Book at
+ http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition has
+ three chapters which detail installation (installing and starting
+ zope), maintenance (maintaining zope) and ZEO (scalability and ZEO).
+ These chapters should be reviewed for inaccuracies with respect to
+ the forthcoming trunk changes and changes should be made "offline"
+ to allow a Zope Book 2.7 edition.
+
+ At least create a HowTo which summarizes the differences between
+ installing 2.6 and installing the trunk.
+
+--------------------------------
+ BEFORE RELEASE OF ZOPE 2.7A
+--------------------------------
+
+Default logging destinations
+
+ If logging parameters are unspecified in the configuration, the
+ default is to log zLOG messages to CLIENT_HOME/event.log and to log
+ access messages to CLIENT_HOME/access.log. This differs from older
+ branches inasmuch as log messages in default mode (aside from
+ startup messages) will no longer be written to stdout.
+ STUPID_LOG_FILE and friends no longer have any effect.
+
+ This is also why logtail is a desirable option (to give back this
+ useful feature).
+
+ This change needs to be communicated in docs and to developers in
+ some way.
+
+
+"configure" shell scripts need peer review
+
+ I'd like someone to review the "configure" and "configure.bat"
+ scripts in the top-level directory and suggest/make changes. These
+ scripts help find a suitable Python interpreter and create a
+ Makefile on UNIX and Windows, respectively.
+
+Find a place for zLOG.DebugLogger and zLOG.AccessLogger
+
+ These packages are placed here because I've got no better place for
+ them. They really don't belong here, as they are the loggers for
+ "detailed" request logging and access logging respectively (not
+ event logging, which is really zLOG's only domain).
+
+Update Zope distribution creation machinery
+
+ The current distribution-creation machinery will almost certainly
+ fail if it's not updated with knowledge of the new Zope installation
+ regime.
+
+Beautify output of "make" and "make install".
+
+ The output of make and make install is ugly.
+
+Get rid of ZOPE_HOME
+
+ An environment variable named ZOPE_HOME was added in 2.6. This
+ envvar is not necessary if ZServer is moved into lib/python. It's
+ usage is cruft and should be exorcised.
+
+ The config schema currently uses a zope_home key. This key and its
+ associated schema handler should go away as well.
+
+
+Zope.Startup.nt.NTService.py and instance_home/bin/ntservice.py need
+testing
+
+ These modules allow you to associate an NT service with a Zope
+ instance_home. Success means being able to invoke the ntservice.py
+ module to create an NT service which can successfully start and stop
+ a Zope instance on a per-instance-home basis.
+
+ Update: As of Jan. 13, this fails -- instance-home-based services
+ report failure on start (even though they start) and cannot be
+ stopped.
+
+What to do about envvars?
+
+ Envvars are still used "under the hood" in ZConfig handlers as the
+ result of particular configuration declarations in order to make
+ Zope do the right thing (e.g. INSTANCE_HOME, SOFTWARE_HOME,
+ DTML_REQUEST_AUTOQUOTE, SESSION_TIMEOUT_MINUTES and other envvars
+ are set in ZConfig handlers for their respective keys). But envvars
+ should not be used to try to configure Zope, as the handlers
+ overwrite existing envvars with prejudice. We need to come down on
+ one side or the other about envvars.. either they should be
+ respected at startup as they always have been or they should be
+ explicitly not respected. Currently they are not respected.
+
+ We need to communicate this decision to developers and update
+ doc/ENVIRONMENT.txt as necessary.
+
+win32-eventlog needs testing
+
+ The "win32-eventlog" log handler (which is creatable via the config
+ file) needs to be tested.
+
+RPM install should recompile .pycs
+
+ The RPM spec file (inst/Zope.spec.in) should delete and recompile
+ .pycs/.pyos during an RPM install to make sure tracebacks contain
+ real Zope filenames instead of filenames relative to the build
+ directory. Alternately the RPM install should not contain .pycs or
+ .pyos.
+
+ XXX Not clear why this is actually needed; importing a module causes
+ the __file__ to be updated with the right filename. A nice touch,
+ but not required.
+
+ AAA Is this a new Python feature or has it always been this way?
+ Tracebacks used to show the location of the .pyc where it had been
+ compiled, not where it actually lived.
+
+RPM install versioning scheme needs to be documented
+
+ The RPM builder has a versioning scheme via the generated Makefile
+ in order to allow for the install of multiple simultaneous versions
+ of Zope on a single system. This versioning scheme should be
+ documented.
+
+Deal with lack of PCGI
+
+ In the old setup style, "w_pcgi.py" was invoked to install Zope with
+ a PCGI ("persistent CGI") socket and files necessary for using Zope
+ in conjunction with Apache/IIS. There are no knobs for installation
+ right now to do the same thing. The 'pcgi' directory still exists
+ in the Zope root dir and the 'make_resource.py' file in "inst" also
+ is available, in case we decide to do something with them.
+
+Server construction errors need to be better
+
+ When a server is constructed, it attempts to bind to a port. If the
+ port cannot be bound, an error is raised. The error currently doesn't
+ include the port number, and should.
+
+
+------------------------------
+ MAYBE NEVER BUT NICE TO HAVE
+------------------------------
+
+ZConfig defaults
+
+ We deferred several issues that we recognized as areas for
+ improvement in ZConfig that might make it possible to avoid writing
+ nasty procedural code for default handling unnecessary
+ (e.g. Zope.Startup.handlers._RootHandler). See
+ http://my.zope.com/CPM/CPM/issues/4 and
+ http://my.zope.com/CPM/CPM/issues/3. Not necessary for merge, but
+ useful to think about for future.
+
- .. which summarizes the differences between installing 2.6 and
- installing 2.7.
-DONE
-----
+------------------------------
+ DONE
+------------------------------
"constructor" conversion in ZConfig.datatypes is ugly
@@ -439,41 +497,24 @@
Done by Chris - Jan 13
-MAJOR DELTAS TO TRUNK
----------------------
-
- - wo_pcgi, w_pcgi, z2.py are gone.
-
- - lib/python/zope.py is "moral equivalent"
- of old z2.py
-
- - Zope now doesn't by default need to be
- run from build directory. "make install"
- creates a distribution dir.
-
- - instance_home setup is now default
- by way of "./configure; make; make install;
- $prefix/bin/mkzopeinst.py".
+"zctl" should have a "logtail" option
- - starting and stopping zope now typically
- performed via "zctl".
+ It should be possible to tail the event, trace, and access logs
+ using zctl (in a cross-platform way).
- - ZLogger package retired.
+ We will be using some variant of zdctl, which has a logtail option.
+ A platform-agnostic (if necessary) TailHelper class was added to
+ zdctl Jan. 26 that can be stolen for this purpose.
- - config file placed in instance_home /etc
- directory.
+Zope.Startup.ZCtlLib needs refactoring
- - inst directory is completely changed and
- contains skeleton directories for both
- "make install" and "make instance" as
- well as other utility programs.
+ Zope.Startup.ZctlLib (zctl's backend) is ugly and could use some
+ refactoring, and possibly a whole new approach to "ctl" should be
+ considered. Maybe instead of spawning a separate process, use a
+ strategy like Guido's runzeo.py, which actually constitutes a
+ mainloop.
- - setup.py has moved into inst directory
- and has been changed to deal with branch
- new packages, package moves, and deals
- better with Windows builds.
+ We won't be refactoring ZCtlLib, we will be using a zdctl variant
+ instead.
- - "make rpmdist" makes a Zope RPM distro.
- - "make testinst" makes the build dir into
- both a software home and an instance_home.