Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi! SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path. So this no longer works in zopectl: ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" Therefore mkzopeinstance now creates something like this: ZDCTL="/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@" Problem: -------- - the code in mkzopeinstance.py that looks up the Zope2 path fails on some platforms - if the software is updated, you have to change the paths in runzope and zopectl of each instance Solution: --------- 1.) Add two new entry points in setup.py: runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:run If the software is installed, executable runzope and zopectl files are created in the bin directory. That should work with zc.buildout and with easy_install. 2.) Modify the runzope and zopectl files created by mkzopeinstance: The result should look like this: ZDCTL="/path/to/install/bin/zopectl" exec "$ZDCTL" -C "$CONFIG_FILE" "$@" mkzopeinstance would make the assumption that executable runzope and zopectl files exist in the same directory as mkzopeinstance itself. Risks: ------ - mkzopeinstance has a --python option. The specified Python interpreter will no longer be used to execute runzope or zopectl. - uses cases might exist that no longer work after that change Any thoughts? Is the 2.12 branch still open for changes like that? Cheers, Yuppie
On 7/23/09 12:10 PM, yuppie wrote:
Hi!
SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path.
So this no longer works in zopectl:
ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@"
Therefore mkzopeinstance now creates something like this:
ZDCTL="/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@"
Problem: --------
- the code in mkzopeinstance.py that looks up the Zope2 path fails on some platforms
- if the software is updated, you have to change the paths in runzope and zopectl of each instance
Solution: ---------
1.) Add two new entry points in setup.py:
runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:run
If the software is installed, executable runzope and zopectl files are created in the bin directory. That should work with zc.buildout and with easy_install.
2.) Modify the runzope and zopectl files created by mkzopeinstance:
The result should look like this:
ZDCTL="/path/to/install/bin/zopectl" exec "$ZDCTL" -C "$CONFIG_FILE" "$@"
mkzopeinstance would make the assumption that executable runzope and zopectl files exist in the same directory as mkzopeinstance itself.
Risks: ------
- mkzopeinstance has a --python option. The specified Python interpreter will no longer be used to execute runzope or zopectl.
- uses cases might exist that no longer work after that change
Any thoughts? Is the 2.12 branch still open for changes like that?
+1 Wichert.
On 23.07.09 12:10, yuppie wrote:
Hi!
SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path.
So this no longer works in zopectl:
ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@"
Therefore mkzopeinstance now creates something like this:
ZDCTL="/path/to/eggs/Zope2-2.12.0b3-py2.5-linux-i686.egg/Zope2/Startup/zopectl.py" exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@"
Problem: --------
- the code in mkzopeinstance.py that looks up the Zope2 path fails on some platforms
- if the software is updated, you have to change the paths in runzope and zopectl of each instance
Solution: ---------
1.) Add two new entry points in setup.py:
runzope=Zope2.Startup.run:run zopectl=Zope2.Startup.zopectl:run
If the software is installed, executable runzope and zopectl files are created in the bin directory. That should work with zc.buildout and with easy_install.
2.) Modify the runzope and zopectl files created by mkzopeinstance:
The result should look like this:
ZDCTL="/path/to/install/bin/zopectl" exec "$ZDCTL" -C "$CONFIG_FILE" "$@"
mkzopeinstance would make the assumption that executable runzope and zopectl files exist in the same directory as mkzopeinstance itself.
Risks: ------
- mkzopeinstance has a --python option. The specified Python interpreter will no longer be used to execute runzope or zopectl.
- uses cases might exist that no longer work after that change
Any thoughts? Is the 2.12 branch still open for changes like that? Go ahead. I also had to fix a similar issue some days ago inside Zope startup code.
Andreas
Andreas Jung wrote:
On 23.07.09 12:10, yuppie wrote:
Any thoughts? Is the 2.12 branch still open for changes like that? Go ahead. I also had to fix a similar issue some days ago inside Zope startup code.
Done. http://svn.zope.org/?rev=102230&view=rev http://svn.zope.org/?rev=102231&view=rev But I couldn't figure out a solution for the zopeservice.py (Windows): The path to the Zope2 egg (ZOPE2PATH) is required to import from nt_svcutils.service. If the Zope2 egg is updated zopeservice.py of each Windows instance has to be updated as well. Cheers, Yuppie
yuppie wrote:
SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path.
So this no longer works in zopectl:
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. If you dig back through the archives, you'll find the buildout.cfg I came up with that works exactly as it should. I had notions of coming up with a generic mkintance package that would package up a buildout.cfg and bootstrap.py into a single executable script called mkzope212instance.py, but never got round to it... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Chris! Chris Withers wrote:
yuppie wrote:
SOFTWARE_HOME no longer exist in Zope 2.12, all the software is now somewhere on sys.path.
So this no longer works in zopectl:
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.
If you dig back through the archives, you'll find the buildout.cfg I came up with that works exactly as it should.
Thanks for the pointer. I was not aware of this thread: http://mail.zope.org/pipermail/zope-dev/2009-April/035973.html Some random thoughts: 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=10... 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. They still set INSTANCE_HOME, but that is redundant if we always set INSTANCE_HOME in zope.conf. 3.) And the zopectl script still sets the PYTHON interpreter. You specify it in zope.conf. I can't see a reason why someone would want to run zopectl with a different interpreter than the Zope instance. Maybe we can make it unnecessary to specify the interpreter. It's just a bit tricky to pass the whole Python path to the subprocess. At least I couldn't figure out a simple and reliable solution. 4.) How do you create zopeservice.py for Windows? Cheers, Yuppie
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...
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=10...
Interesting. I never noticed that... Hopefully that change will make it into Zope 2.12 final?
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?
3.) And the zopectl script still sets the PYTHON interpreter. You specify it in zope.conf. I can't see a reason why someone would want to run zopectl with a different interpreter than the Zope instance.
Indeed. I'd suggest that if the python used to run zopectl is different to the one specified in runzope, there will be problems. My guess is that these are just symptoms of how runzope and zopectl used to be construted...
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...
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... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 14/08/2009 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...
zope2 releases based on buildout make it very hard for distributors to package zope2. especially as zope2 requires from what i know about buildout (and that's not much), it either requires a working internet connection or a local mirror with exact versions of all required python eggs. i would highly appreciate a final release tarball which includes all required python library/module eggs. greetings, jonas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Meurer wrote:
zope2 releases based on buildout make it very hard for distributors to package zope2. especially as zope2 requires from what i know about buildout (and that's not much), it either requires a working internet connection or a local mirror with exact versions of all required python eggs.
Any distributor packaging Zope should be able to assemble the collection of required eggs separately (it doesn't need to be a "mirror").
i would highly appreciate a final release tarball which includes all required python library/module eggs.
Sorry, we aren't making such tarballs any longer. Distributors who don't want to package the broken-out eggs separately will need to synthesize such a beast, perhaps using something like 'zc.sourcerelease'. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKhZPu+gerLs4ltQ4RAjD2AKCdTnqA3+o7zIKfx/4U9L92WVBajACgqEvp tlHYgPu028FpcnuSK8FSnLQ= =RGUh -----END PGP SIGNATURE-----
Tres Seaver wrote:
Sorry, we aren't making such tarballs any longer. Distributors who don't want to package the broken-out eggs separately will need to synthesize such a beast, perhaps using something like 'zc.sourcerelease'.
I was just about to suggest this. I haven't used it, but my understanding is that it's exactly what it's for... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer<jonas@freesources.org> wrote: ...
zope2 releases based on buildout make it very hard for distributors to package zope2. especially as zope2 requires from what i know about buildout (and that's not much), it either requires a working internet connection or a local mirror with exact versions of all required python eggs.
i would highly appreciate a final release tarball which includes all required python library/module eggs.
This ought to be easy using zc.sourcerelease. We (zc) use it to make self-contained tar balls from which we build rpms. Jim -- Jim Fulton
On 14/08/2009 Jim Fulton wrote:
On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer<jonas@freesources.org> wrote: ...
zope2 releases based on buildout make it very hard for distributors to package zope2. especially as zope2 requires from what i know about buildout (and that's not much), it either requires a working internet connection or a local mirror with exact versions of all required python eggs.
i would highly appreciate a final release tarball which includes all required python library/module eggs.
This ought to be easy using zc.sourcerelease. We (zc) use it to make self-contained tar balls from which we build rpms.
yes, thanks for suggesting that. i don't know much about buildout, and didn't give zc.sourcerelease a try yet, but i'll take a look at it. are the scripts you use to make self-contained tar balls and maybe even the build scripts for rpms available somewhere? i guess they would be of great help for me to understand how zc.sourcerelease works. greetings, jonas
Hello, On Fri, Aug 14, 2009, Jim Fulton wrote:
On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer <jonas@freesources.org> wrote: ...
zope2 releases based on buildout make it very hard for distributors to package zope2. especially as zope2 requires from what i know about buildout (and that's not much), it either requires a working internet connection or a local mirror with exact versions of all required python eggs.
i would highly appreciate a final release tarball which includes all required python library/module eggs.
This ought to be easy using zc.sourcerelease. We (zc) use it to make self-contained tar balls from which we build rpms.
do you have any examples how to use zc.sourcerelease for that purpose? i see that this is the right utility, but i fail to understand how it works up to now. the whole buildout stuff is fairly new to me. it would be great if you had an example script with zc.sourcerelease which creates a source tarball for zope2.12. if i got it right i need buildout.cfg for zc.sourcerelease which describes how to create the tarball. and then i need a second buildout.cfg for zope2.12 which describes how to actually build zope2.12 from the sources that zc.sourcerelease put together, right? greetings, and thanks in advance, jonas
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=10...
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
yuppie wrote:
Currently buildout is just used to set up the software.
Wrong. The buildout I posted, which uses no fancy recipes, sets up an instance. The egg cache, as such, is "the software"...
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.
So tell us where it's not best rather than just asserting that such a use case exists ;-)
mkzopeinstance helps to draw a line between software and data.
No it doesn't. Plenty of software can live in an instance. IMNSHO, buildout does a *better* job of drawing a line between software and data...
that's important for distributors who want to distribute generic software, not user specific instance setups.
Distributors just want a tarball or similar, let them use zc.sourcerelease and have a slightly different buildout.cfg, or even default.cfg, which uses that tarball as the source of eggs rather than PyPI...
And sometimes it is useful to link an existing instance to a new buildout by updating some paths in instance/bin.
I don't understand this. Please explain more...
Or to create several instances based on one buildout.
Why?
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.
Cool :-)
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?
I meant I nicer way of passing in the location of zope.conf...
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).
They're all the same python...
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.
Sure, I can't imagine it's a particularly hard problem, it's just not one the I'm interested in solving... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Chris! Chris Withers wrote:
yuppie wrote:
Currently buildout is just used to set up the software.
Wrong. The buildout I posted, which uses no fancy recipes, sets up an instance. The egg cache, as such, is "the software"...
You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Of course buildout in general is used in many ways and often for setting up instances.
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.
So tell us where it's not best rather than just asserting that such a use case exists ;-)
mkzopeinstance helps to draw a line between software and data.
No it doesn't. Plenty of software can live in an instance. IMNSHO, buildout does a *better* job of drawing a line between software and data...
that's important for distributors who want to distribute generic software, not user specific instance setups.
Distributors just want a tarball or similar, let them use zc.sourcerelease and have a slightly different buildout.cfg, or even default.cfg, which uses that tarball as the source of eggs rather than PyPI...
And sometimes it is useful to link an existing instance to a new buildout by updating some paths in instance/bin.
I don't understand this. Please explain more...
Or to create several instances based on one buildout.
Why?
I guess the scenario you have in mind is a lightweight buildout that just contains some .cfg files describing the instance. There is nothing wrong about using buildout that way, but maybe it's wrong to make it the only supported way. The scenario I have in mind is a buildout that contains several development eggs. In that case it is expensive to update and rebuild a buildout. And you might have local changes in that buildout. These buildouts are more 'software' than 'instance'. Maybe with that scenario my assertions make more sense to you?
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?
I meant I nicer way of passing in the location of zope.conf...
If you create the instance in the same step your solution doesn't look that bad. And if you use mkzopeinstance the command line option seems to be the right way to specify zope.conf.
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).
They're all the same python...
Exactly. But if we always use the same Python, why do we have to specify it in several places?
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.
Sure, I can't imagine it's a particularly hard problem, it's just not one the I'm interested in solving...
That makes two of us. If nobody wants to do the work, your proposal is moot. Cheers, Yuppie
yuppie wrote:
yuppie wrote:
Currently buildout is just used to set up the software.
Wrong. The buildout I posted, which uses no fancy recipes, sets up an instance. The egg cache, as such, is "the software"...
You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances.
Sure it does. I've published the recipe. There's no more needed than that...
And sometimes it is useful to link an existing instance to a new buildout by updating some paths in instance/bin.
I don't understand this. Please explain more...
Still waiting for you to explain this more...
Or to create several instances based on one buildout.
Why?
I guess the scenario you have in mind is a lightweight buildout that just contains some .cfg files describing the instance.
Indeed, or any software that's local to that instance and isn't distributed as an egg.
There is nothing wrong about using buildout that way, but maybe it's wrong to make it the only supported way.
Why? It should be fairly trivial to make mkzopeinstance a script that unpacks bootstrap.py and constructs the skeleton directories, zope.conf and buildout.cfg. I really don't see what more is needed than that?
The scenario I have in mind is a buildout that contains several development eggs. In that case it is expensive to update and rebuild a buildout.
No it isn't.
And you might have local changes in that buildout.
What does that have to do with anything?
These buildouts are more 'software' than 'instance'. Maybe with that scenario my assertions make more sense to you?
Nope. As I said, The "Zope 2.12" software will never be in such a buildout, just used by it. As such, the "egg cache" wherever and however you have it becomes the "Zope 2.12" software... Anything in the buildout is "software" that is local to that instance, like Products or External Methods used to be in days of old...
I meant I nicer way of passing in the location of zope.conf...
If you create the instance in the same step your solution doesn't look that bad.
I don't know what you mean by this...
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).
They're all the same python...
Exactly. But if we always use the same Python, why do we have to specify it in several places?
Huh? You don't...
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.
Sure, I can't imagine it's a particularly hard problem, it's just not one the I'm interested in solving...
That makes two of us. If nobody wants to do the work, your proposal is moot.
*sigh* By all means, please do go ahead and make more work for yourself ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Chris! Chris Withers wrote:
yuppie wrote:
yuppie wrote:
Currently buildout is just used to set up the software. Wrong. The buildout I posted, which uses no fancy recipes, sets up an instance. The egg cache, as such, is "the software"... You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances.
Sure it does. I've published the recipe. There's no more needed than that...
Your recipe is not published as part of Zope 2.12. And it doesn't work on Windows. [...]
These buildouts are more 'software' than 'instance'. Maybe with that scenario my assertions make more sense to you?
Nope. As I said, The "Zope 2.12" software will never be in such a buildout, just used by it. As such, the "egg cache" wherever and however you have it becomes the "Zope 2.12" software... Anything in the buildout is "software" that is local to that instance, like Products or External Methods used to be in days of old...
Are you ignoring the fact that buildouts with several dev eggs exist? Or do you define all dev eggs as local to the instance? For development I regularly use one dev buildout with several different test instances. The dev eggs are local to my dev buildout, but not local to the test instances.
I meant I nicer way of passing in the location of zope.conf... If you create the instance in the same step your solution doesn't look that bad.
I don't know what you mean by this...
You propose to create the entry point and the instance in the same step. And you have these lines in your buildout.cfg: initialization = import sys sys.argv[1:1] = ['-C','${buildout:directory}/etc/zope.conf'] Why are you not happy with that solution?
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). They're all the same python... Exactly. But if we always use the same Python, why do we have to specify it in several places?
Huh? You don't...
Your buildout.cfg creates an interpreter entry point 'py'. Your zope.conf.in specifies "python $INSTANCE/bin/py". But the zopectl entry point already contains all the information it needs. runzope doesn't depend on 'py'. Why does zopectl have to look up the interpreter path in zope.conf und use 'py'? Cheers, Yuppie
yuppie wrote:
You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Sure it does. I've published the recipe. There's no more needed than that...
Your recipe is not published as part of Zope 2.12.
I'm not sure it needs to...
And it doesn't work on Windows.
Have you tried it?
Nope. As I said, The "Zope 2.12" software will never be in such a buildout, just used by it. As such, the "egg cache" wherever and however you have it becomes the "Zope 2.12" software... Anything in the buildout is "software" that is local to that instance, like Products or External Methods used to be in days of old...
Are you ignoring the fact that buildouts with several dev eggs exist? Or do you define all dev eggs as local to the instance?
I don't really see what you're driving at here... "dev eggs" are just lines in {buildout:develop}, where they point to doesn't matter so I don't know what you mean by "local to the instance"...
For development I regularly use one dev buildout with several different test instances.
Can you post an example buildout.cfg, and what your instances look like, since I don't reall understand what you're doing...
The dev eggs are local to my dev buildout, but not local to the test instances.
What does this actually mean? For me, a "dev egg" is usually just an svn checkout, specified in {buildout:develop}. For me, they're never usually in any "buildout", unless the package itself is buildout-driven and I'm actually developing it, but that has nothing to do with my test instances... That said, I often use a few "dev eggs" that aren't buildout driven at all, so I really fail to see your point...
I meant I nicer way of passing in the location of zope.conf... If you create the instance in the same step your solution doesn't look that bad. I don't know what you mean by this...
You propose to create the entry point and the instance in the same step.
What is "the instance" you're referring to here?
And you have these lines in your buildout.cfg:
initialization = import sys sys.argv[1:1] = ['-C','${buildout:directory}/etc/zope.conf']
Why are you not happy with that solution?
It feels icky...
Exactly. But if we always use the same Python, why do we have to specify it in several places? Huh? You don't...
Your buildout.cfg creates an interpreter entry point 'py'. Your zope.conf.in specifies "python $INSTANCE/bin/py".
That would never need to be changed be anyone using a buildout-based instance. If buildout was blessed as "the right way", it could disappear into a default and nto even need to be included.
But the zopectl entry point already contains all the information it needs. runzope doesn't depend on 'py'. Why does zopectl have to look up the interpreter path in zope.conf und use 'py'?
I dunno, ask whoever wrote zdaemon ;-) If it's not specified, it just uses "python", which won't have the buildout's eggs available. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
(updating myself much much later) Chris Withers wrote:
yuppie wrote:
You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Sure it does. I've published the recipe. There's no more needed than that...
Your recipe is not published as part of Zope 2.12.
I'm not sure it needs to...
It will be once Jens cranks the handle: http://svn.zope.org/Zope/branches/2.12/doc/INSTALL.rst?rev=104817&view=auto
And it doesn't work on Windows.
Have you tried it?
...if you had, you would have noticed that the Win32 service stuff as broken, even without using buildout. I've now fixed that, and I'm happy to report that the buildout-based instances work just fine on Windows, and buildout instance or not, you no longer need that silly zopeservice.py file in your instance. So, no excuse for needing mkzopeinstance and its ilk anymore ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Hi Chris! Chris Withers wrote:
(updating myself much much later)
(replying much much later)
Chris Withers wrote:
yuppie wrote:
You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Sure it does. I've published the recipe. There's no more needed than that... Your recipe is not published as part of Zope 2.12. I'm not sure it needs to...
It will be once Jens cranks the handle:
http://svn.zope.org/Zope/branches/2.12/doc/INSTALL.rst?rev=104817&view=auto
And it doesn't work on Windows. Have you tried it?
...if you had, you would have noticed that the Win32 service stuff as broken, even without using buildout.
No. I did have tried with mkzopeinstance and zopeservice.py. And it did work for me.
I've now fixed that, and I'm happy to report that the buildout-based instances work just fine on Windows, and buildout instance or not, you no longer need that silly zopeservice.py file in your instance.
That's a great improvement. I just found a small regression, see https://bugs.launchpad.net/zope2/+bug/461446
So, no excuse for needing mkzopeinstance and its ilk anymore ;-)
In some situations I still prefer the classic way to create instances. You might have noticed that the "Creating a classic Zope Instance" section in INSTALL.rst is much simpler than the "Creating a buildout-based Zope Instance" section. And there is still the question about the right way to work with dev eggs. I quote your question from an other mail in this thread because I didn't answer it so far:
The dev eggs are local to my dev buildout, but not local to the test instances.
What does this actually mean? For me, a "dev egg" is usually just an svn checkout, specified in {buildout:develop}. For me, they're never usually in any "buildout", unless the package itself is buildout-driven and I'm actually developing it, but that has nothing to do with my test instances... That said, I often use a few "dev eggs" that aren't buildout driven at all, so I really fail to see your point...
http://svn.zope.org/repos/main/CMF.buildout/trunk has a src directory with several svn externals. Buildout includes the dev eggs from the src directory. http://svn.plone.org/svn/plone/buildouts/plone-coredev/trunk uses mr.developer to use the src directory in a similar way. The dev eggs are created before running the buildout command, but they belong to a specific buildout. That sometimes makes "buildout-based" Zope instances more clumsy than classic instances. Cheers, Yuppie
yuppie wrote:
And it doesn't work on Windows. Have you tried it? ...if you had, you would have noticed that the Win32 service stuff as broken, even without using buildout.
No. I did have tried with mkzopeinstance and zopeservice.py. And it did work for me.
I'm surprised. It certainly didn't for me and I don't see how it could for anyone else.
I've now fixed that, and I'm happy to report that the buildout-based instances work just fine on Windows, and buildout instance or not, you no longer need that silly zopeservice.py file in your instance.
That's a great improvement. I just found a small regression, see https://bugs.launchpad.net/zope2/+bug/461446
Not a very clear bug report...
So, no excuse for needing mkzopeinstance and its ilk anymore ;-)
In some situations I still prefer the classic way to create instances.
There's always a few odd people out there ;-)
You might have noticed that the "Creating a classic Zope Instance" section in INSTALL.rst is much simpler than the "Creating a buildout-based Zope Instance" section.
When the new docs go live, you'll see things have changed...
The dev eggs are local to my dev buildout, but not local to the test instances. What does this actually mean? For me, a "dev egg" is usually just an svn checkout, specified in {buildout:develop}. For me, they're never usually in any "buildout", unless the package itself is buildout-driven and I'm actually developing it, but that has nothing to do with my test instances... That said, I often use a few "dev eggs" that aren't buildout driven at all, so I really fail to see your point...
http://svn.zope.org/repos/main/CMF.buildout/trunk has a src directory with several svn externals. Buildout includes the dev eggs from the src directory.
I still don't really understand the use case here. My guess would be that if you want to work with a trunk checkout of CMF, all you need to do is at that src path to the "develop" line in the [buildout] section.
That sometimes makes "buildout-based" Zope instances more clumsy than classic instances.
I don't see how the stuff you're describing would be any less clumsy using a classic instance... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 24/08/2009 Chris Withers wrote:
that's important for distributors who want to distribute generic software, not user specific instance setups.
Distributors just want a tarball or similar, let them use zc.sourcerelease and have a slightly different buildout.cfg, or even default.cfg, which uses that tarball as the source of eggs rather than PyPI...
do you have any example code on how to do that? greetings, jonas
participants (7)
-
Andreas Jung -
Chris Withers -
Jim Fulton -
Jonas Meurer -
Tres Seaver -
Wichert Akkerman -
yuppie