The following is a TODO list dealing with installation and startup changes proposed for the Zope trunk. It is organized into these categories: "BEFORE 2.7 FINAL" (things that need to be done before we're finished, but not currently on the critical path) "MAYBE NEVER BUT NICE TO HAVE" (items that are not on any critical path) "COMMUNITY CONCERNS" (uncategorized concerns dealing with features missing from HEAD and prior 2.7 releases) ---------------------------------- BEFORE RELEASE OF ZOPE 2.7 FINAL ---------------------------------- Provide more intuitive command line option overrides Currently, you can override config file options by using the -X command line switch to runzope.py, followed by key/value pairs separated by an equal sign. This isn't explained anywhere and I'm not sure what limitations it has (can you change any value in the config file this way?). Zope-specific command-line options that don't require the -X (e.g. --event-log-file=something) should be provided to the user via changes to Zope/Startup/options/ZopeOptions. Make 'runzope -h' work and give better error messages when a configuration fails to make the grade. Currently runzope -h just emits a traceback, and the message printed by run.py says to run 'run.py -h' which can't work because things that it needs to import aren't on the PYTHONPATH. Config file needs better inline docs The Zope ZConfig config file has some inline docs. They need to be completed. Additional docs may come as a result of writing a schema-to-HTML translator. Make as many things defaultable as feasible Maybe we can allow a config file in which everything is commented out. We'll see. Write some more unit tests Write unit tests for Zope.Startup packages. 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. Note: As of Jul 6, 2003, it has been confirmed to not work. The service name that it is logging under ("Zope") is not registered with the NT event service properly, causing a warning to be written to the log every time a log call is made. 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. I propose that we add two more options to the config file: Create import-directory and extensions-directory directives These would both be multikeys which specify some number of directories that contained importable zexp files and external methods, respectively. This would allow us to not require any fixed instance home directory. Instead, each path required by each subsystem is specifiable by itself in the config file. I'm sure that utilizing these options in the config file will break things that rely on having a monolithic INSTANCE_HOME such as products that attempt to do something like "import_dir = os.path.join(INSTANCE_HOME, 'import'). So I propose that the stock Zope instance home install continue to follow the old pattern (where everything is installed into a single instance home directory), but we provide the advanced config file options for roll-your-own packagers and advanced users. I would like to do the same thing for the software home, but I haven't thought much about it yet. Review the Zope Book 2.6 Edition chapters and come up with revisions or at least create a Zope 2.7 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 2.7. ------------------------------ 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.root_handler). 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. ZConfig should keep enough state to be able to reconstitute the textual representation of the configuration. It would be nice if ZConfig kept enough state to be able to reconstitute the configuration in textual representation (to aid GUI builders and to make it possible to have a meaningful 'zopectl showconfig' or somesuch). ---------------------------------- COMMUNITY CONCERNS (uncategorized) ---------------------------------- Status: Request for comment sent to the community: http://mail.zope.org/pipermail/zope-dev/2003-March/018999.html Lots of discussion! - ZConfig is too complex when compared with envvar parsing. - Somewhat unrelated, but the features of "debug mode" should be disentangled from one another and specifiable individually. - Need to support arbitrary storage types. - Provide --swhome and ---with-python switch to mkzopeinstance, which will allow folks to create an instance that points to particular (known) Python versions and software homes. XXX This doesn't make sense. mkzopeinstance is part of the software home; if you want to use a different one, use the mkzopeinstance from the software home you want to use. The same goes for the Python to use; that's "built-in" to a software home. Using a different Python doesn't make sense given that the software home includes compiled modules. AAA This is to service to-be-chrooted installs. - Explain how to set up and use a ZEO server using mkzeoinst included in 2.7's ZEO. (Use the installed bin/mkzeoinstance script; use --help for more information.) Richard Jones has done work to allow you to create a ZEO instance in a way similar to creating a Zope instance (yay!) after creating a software home. - Give ZConfig replacement access to the environment or shell somehow. For instance, some folks use the same 'start' script in all of their instances right now (under 2.6). The script does things based on the value of an envvar that can be used to distinguish the config values of the instance from other instances. We could allow for the same sort of behavior E.g.: %define HOSTNAME `hostname` (assuming `hostname` resolves to a hostname) lockfile-name /var/lock/$HOSTNAME-lockfile - Give installaler an option to put libs in a user-specifiable directory at software home installation time. - Give installer an option to put docs in a user-specifiable directory at software home installation time. - Make it possible to install Zope-related Python libraries to The site-packages of the Python used to invoke setup.py. - Offer to install software home 'bin' scripts into a directory separate from the software home 'bin' directory. - Allow for the installation of platform-dependent files (basically Python extensions) to be installed to a place separate than that of platform independent files (as requested by Luca DeVitis). - Upon failure of Windows service startup, it's possible for the reason for the failure to not be logged anywhere. This is because we carefully wait til late in the startup process to write logfiles so UNIX has a chance to setuid. This is unnecessary for Windows.