Mailing List Archive: Zope: Dev

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

Index | Next | Previous | View Threaded

y.2009 at wcm-solutions

Jul 23, 2009, 3:10 AM

Post #1 of 23 (1973 views)
Permalink

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

wichert at wiggy

Jul 23, 2009, 3:31 AM

Post #2 of 23 (1904 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

lists at zopyx

Jul 23, 2009, 5:13 AM

Post #3 of 23 (1901 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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

Attachments:

lists.vcf (0.31 KB)

y.2009 at wcm-solutions

Jul 24, 2009, 5:32 AM

Post #4 of 23 (1889 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

chris at simplistix

Aug 9, 2009, 3:28 PM

Post #5 of 23 (1740 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

y.2009 at wcm-solutions

Aug 10, 2009, 1:44 AM

Post #6 of 23 (1740 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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=101795&r2=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[at]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 )

chris at simplistix

Aug 14, 2009, 8:16 AM

Post #7 of 23 (1680 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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=101795&r2=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[at]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 )

jonas at freesources

Aug 14, 2009, 9:30 AM

Post #8 of 23 (1680 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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

Attachments:

signature.asc (0.19 KB)

tseaver at palladion

Aug 14, 2009, 9:42 AM

Post #9 of 23 (1681 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

-----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[at]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-----

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

chris at simplistix

Aug 14, 2009, 9:45 AM

Post #10 of 23 (1679 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

jim at zope

Aug 14, 2009, 9:50 AM

Post #11 of 23 (1680 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer<jonas[at]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[at]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 )

jonas at freesources

Aug 15, 2009, 1:59 PM

Post #12 of 23 (1649 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

On 14/08/2009 Jim Fulton wrote:
> On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer<jonas[at]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[at]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 )

y.2009 at wcm-solutions

Aug 18, 2009, 3:22 AM

Post #13 of 23 (1596 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

chris at simplistix

Aug 24, 2009, 3:28 PM

Post #14 of 23 (1427 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

y.2009 at wcm-solutions

Aug 25, 2009, 3:01 AM

Post #15 of 23 (1419 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

jonas at freesources

Aug 25, 2009, 5:20 PM

Post #16 of 23 (1411 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

Hello,

On Fri, Aug 14, 2009, Jim Fulton wrote:
> On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer <jonas[at]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

Attachments:

signature.asc (0.19 KB)

jonas at freesources

Aug 25, 2009, 5:40 PM

Post #17 of 23 (1408 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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

Attachments:

signature.asc (0.19 KB)

chris at simplistix

Aug 31, 2009, 4:29 AM

Post #18 of 23 (1279 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

y.2009 at wcm-solutions

Aug 31, 2009, 7:03 AM

Post #19 of 23 (1275 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

chris at simplistix

Sep 7, 2009, 4:35 AM

Post #20 of 23 (1121 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

chris at simplistix

Oct 5, 2009, 5:34 PM

Post #21 of 23 (760 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

(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
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

y.2009 at wcm-solutions

Oct 26, 2009, 2:18 PM

Post #22 of 23 (460 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

chris at simplistix

Oct 27, 2009, 6:40 AM

Post #23 of 23 (451 views)
Permalink

Re: Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal [In reply to]

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[at]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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com