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