Hi Chris!
Chris Withers wrote: > yuppie wrote: >>>> ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" >>>> exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" >>> I wish we could just bless buildout as "the way" to set up Zope 2.12, >>> then mkzopeinstance becomes moot. >> Not everybody agrees with that. But nevertheless, both approaches can >> learn from each other and become more similar. > > Are you one of the people who doesn't agree? If so, what's your problem > with buildout? Hopefully we can sort that rather than having to maintain > two ways of doing things... IMHO it is a good thing to try to keep the setup procedure as generic as possible. Even though I don't use the virtualenv/easy_install pattern. But the more important question is *how* buildout is used: Currently buildout is just used to set up the software. mkzopeinstance is used to set up instances. And while I see that using buildout for setting up everything in one step has some advantages, it's not the best pattern for all use cases. mkzopeinstance helps to draw a line between software and data. AFAICS that's important for distributors who want to distribute generic software, not user specific instance setups. And sometimes it is useful to link an existing instance to a new buildout by updating some paths in instance/bin. Or to create several instances based on one buildout. >> 1.) mkzopeinstance now also uses entry points for runzope and zopectl. >> zopectl did have some code in the "__name__ == '__main__'" section, so I >> added a small 'run' wrapper for 'main': >> http://svn.zope.org/Zope/trunk/src/Zope2/Startup/zopectl.py?rev=102009&r1=101795&r2=102009 > > Interesting. I never noticed that... Hopefully that change will make it > into Zope 2.12 final? Yes. I made that change on the 2.12 branch as well. >> 2.) The runzope and zopectl scripts created by mkzopeinstance are now >> basically small wrappers that pass the config file location to the entry >> point scripts. > > Cool. If only the zope2 egg could expose these now, it would make the > buildout.cfg simpler... just the matter of passing in the config. I > wonder if anyone can think of a nicer way of doing that? runzope and zopectl are defined as entry points: http://svn.zope.org/Zope/tags/2.12.0b4/setup.py?rev=102515&view=auto Or did you mean something else? >> Maybe >> we can make it unnecessary to specify the interpreter. > > When runzope and zopectl are built by buildout, this is already the > case... One python is used for both... No. Currently you also need 'zopepy' (or 'py' in your case). zopectl uses self.options.python to run several commands. Quoting some lines from zopectl: def get_startup_cmd(self, python, more): cmdline = ( '%s -c "from Zope2 import configure;' 'configure(\'%s\');' % (python, self.options.configfile) ) return cmdline + more + '\"' def do_debug(self, arg): cmdline = self.get_startup_cmd(self.options.python + ' -i', 'import Zope2; app=Zope2.app()') print ('Starting debugger (the name "app" is bound to the top-level ' 'Zope object)') os.system(cmdline) >> 4.) How do you create zopeservice.py for Windows? > > What's Windows? Seriously though, I haven't needed to run Zope 2.12 on > Windows, so I don't know... But we have to support Windows. And I was able to get zopeservice.py running with mkzopeinstance. *If* we decide to use buildout the way you propose, someone has to figure out how to create zopeservice.py without mkzopeinstance. Cheers, Yuppie _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )