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.

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).  

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.

----------------------------------
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 installation time.

 - Give installer an option to put docs in a user-specifiable directory
   at software home installation time.

 - Give installer an option to put instance skeleton files 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.

 - To help binary distribution creators, mkzopeinstance probably needs
   to make it easier to place instance files in separate directories
   and needs to generate a zope.conf that reflects
   logfile/lockfile/pidfile placement options that can be fed on the
   command line.

 - Allow a custom Zope.conf.in to be used by someone invoking
   mkzopeinstance?

 - 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).

