Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=104817view=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
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
(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=104817view=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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=102515view=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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hello, On Fri, Aug 14, 2009, Jim Fulton wrote: On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer jo...@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 signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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 signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=102515view=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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=102009r1=101795r2=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=102515view=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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
On 14/08/2009 Jim Fulton wrote: On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurerjo...@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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=102009r1=101795r2=102009 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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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 signature.asc Description: Digital signature ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurerjo...@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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=102009r1=101795r2=102009 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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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=102230view=rev http://svn.zope.org/?rev=102231view=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 ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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. ___ 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 )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
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 begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
