[Zope-dev] app = Zope.app() backwards incompatibility notice / discussion

[Chris McDonough]

The extant "import Zope; app = Zope.app()" dance to get a hold of the
Zope root object stopped working long ago on the 2.7 branch and HEAD due
to the new configuration machinery, which implies that users be explicit
about configuration settings rather than allowing Zope to guess.

Up til now, the dance to get Zope 2.7 to start properly from within a
script was byzantine and obscure.  I've made a checkin which makes it a
little easier (or at least I'm about to as soon as the full unit test
suite comes back passed ;-).

Code which used to do:

 import Zope
 app = Zope.app()

Will need to do this under 2.7b4+:

 import Zope
 Zope.configure('/path/to/configfile')
 app = Zope.app()

(I wont bother telling you what the dance was for 2.7 before now, it was
pretty awful).

I realize this is suboptimal from a backwards compatibility perspective,
but I'm not sure how to make it any better, seeing as the config file
has some fairly important information in it (like which databases to
use) and guessing would be very bad in this context.

Jim Roepke suggested that if an "ZOPE_CONFIG" envvar was set with the
config file path, that "import Zope; Zope.app()" could be made to "just
work", but I'm not sure this is any better than requiring that
developers change their scripts.  Guessing at the config file location
is also fraught with problems, and I'd be hesitant to do it.

I'm apt just to recommend that we require that developers add the
"Zope.configure(filename)" line to their scripts as opposed to doing
anything more magical.  I'm sure there will be indignant wails about it,
but c'est la vie. ;-)

Note that FWIW, you can also do (on UNIX):

  zopectl run <scriptname>

.. which will run a script with the name "app" set up as the root Zope
application object.  This might be the easiest way to run scripts which
need to operate against Zope objects going forward.

- C