[Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal

[yuppie]

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