Re: [Zope-dev] Summary of this weeks' meeting
On 04/09/2010 05:30 AM, Jan Smith wrote: > Hi Christian, > >> From: Christian Theune >> To: zope-dev@zope.org >> Date: Wed, 31 Mar 2010 17:16:38 +0200 >> Subject: [Zope-dev] Summary of this weeks' meeting (2010-03-30) >> Hi, >> >> here's this week's summary. >> >> For those of you who can't/don't participate in those meetings, there's the >> open >> question about how useful you consider my summaries to be. Please tell! > > Your summaries are extremely useful for people on the other side of > the planet. The irc meetings are held at 3pm UTC - this is sleeping > time for most of us downunder and means it's difficult to participate. > > I've published the irc meeting summaries on the Australian OzZope site > - it also has an rss feed available. > http://www.ozzope.org/weekly-zope-development-meeting Cool - thanks! -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
[Zope-dev] Summary of this weeks' meeting
Hi Christian, > From: Christian Theune > To: zope-...@zope.org > Date: Wed, 31 Mar 2010 17:16:38 +0200 > Subject: [Zope-dev] Summary of this weeks' meeting (2010-03-30) > Hi, > > here's this week's summary. > > For those of you who can't/don't participate in those meetings, there's the > open > question about how useful you consider my summaries to be. Please tell! Your summaries are extremely useful for people on the other side of the planet. The irc meetings are held at 3pm UTC - this is sleeping time for most of us downunder and means it's difficult to participate. I've published the irc meeting summaries on the Australian OzZope site - it also has an rss feed available. http://www.ozzope.org/weekly-zope-development-meeting Jan Smith http://www.ozzope.org/ > > Also in short: we decided to keep going with the meetings, so I'd be happy to > see you guys next week in #zope. (Hopefully without screwing up the time > then.) > > Christian > > -- > Christian Theune · c...@gocept.com > gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany > http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 > Zope and Plone consulting and development > ___ 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] Stacking zope.component registries
On Thursday 08 April 2010, Martin Aspeli wrote: > Right. However, any calls to provideAdapter() and friends would still > use the global registry, unless I monkey patch > zope.component.globalregistry.base, as would any ZCML directives, I guess. That's not really monkey patching. :-) I would consider this a valid part of the API. :-) Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ 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] Stacking zope.component registries
Stephan Richter wrote:
> On Thursday 08 April 2010, Martin Aspeli wrote:
>> Can you elaborate on what you mean here?
>
> So I think this can all be done independently of base registry (unless you are
> are planning to store the registry in the ZODB).
>
> The key for layering is the ability to inherit components using the __bases__
> attribute (see registry.py). So something like:
>
> reg1 = Components('reg1') # Registry for layer 1
>
> Then for the next layer that is based on layer 1, you can do:
>
> reg2 = Components('reg2', (reg1,)) # Registry for layer 2
>
> This should behave identically to how ZODB storage layering works.
Right. However, any calls to provideAdapter() and friends would still
use the global registry, unless I monkey patch
zope.component.globalregistry.base, as would any ZCML directives, I guess.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
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] Stacking zope.component registries
On Thursday 08 April 2010, Martin Aspeli wrote:
> Can you elaborate on what you mean here?
So I think this can all be done independently of base registry (unless you are
are planning to store the registry in the ZODB).
The key for layering is the ability to inherit components using the __bases__
attribute (see registry.py). So something like:
reg1 = Components('reg1') # Registry for layer 1
Then for the next layer that is based on layer 1, you can do:
reg2 = Components('reg2', (reg1,)) # Registry for layer 2
This should behave identically to how ZODB storage layering works.
Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"
___
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] Stacking zope.component registries
Stephan Richter wrote: > On Thursday 08 April 2010, Martin Aspeli wrote: >> Yes, I did look at it. However, the real goal is to provide isolation >> for "anything" that makes ZCA registrations. In particular, that >> includes provideAdapter() and friends. I suspect z3c.baseregistry can't >> deal with this? > > I think it can be done, just not in the way I intended it to. Instead of > adding the base registry to bases, you have to make it the actual registry for > the API, which should be no problem from a functional test setup function. Can you elaborate on what you mean here? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] Stacking zope.component registries
On Thursday 08 April 2010, Martin Aspeli wrote: > Yes, I did look at it. However, the real goal is to provide isolation > for "anything" that makes ZCA registrations. In particular, that > includes provideAdapter() and friends. I suspect z3c.baseregistry can't > deal with this? I think it can be done, just not in the way I intended it to. Instead of adding the base registry to bases, you have to make it the actual registry for the API, which should be no problem from a functional test setup function. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ 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] Stacking zope.component registries
Chris McDonough wrote: > On 4/8/10 4:36 PM, Marius Gedminas wrote: >>> from zope.component import getSiteManager >>> getSiteManager.sethook(get_current_registry) >> That seems a bit short-sighted: it would break all tests that rely on >> setSite() working. > > He said he wanted a global registry, but.. who knows? I stay as far away from > that API as possible. ;-) Marius is right - I need standard stuff like setSite(), local components and that pesky global API (provideAdapter etc.) to work. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] Stacking zope.component registries
Stephan Richter wrote: > On Thursday 08 April 2010, Marius Gedminas wrote: >> Someone (I'm bad with names, sorry!) recently proposed a change to >> zope.configuration that makes ZCML directives use getSiteManager() >> instead of getGlobalSiteManager(); with that patch in, Chris's example >> should make ZCML configuration register all the components into your >> stacked registry. Although you'd have the other problem of setSite() >> having no effect on the site manager, which would break all local >> utilities and adapters in your tests. > > What about using z3c.baseregistry? You can wrap the baseregistry call around > your ZCML. This way you can create on registry per layer and then use the > __bases__ attribute to stack them together. Yes, I did look at it. However, the real goal is to provide isolation for "anything" that makes ZCA registrations. In particular, that includes provideAdapter() and friends. I suspect z3c.baseregistry can't deal with this? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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] Stacking zope.component registries
On 4/8/10 4:36 PM, Marius Gedminas wrote: >> >> from zope.component import getSiteManager >> getSiteManager.sethook(get_current_registry) > > That seems a bit short-sighted: it would break all tests that rely on > setSite() working. He said he wanted a global registry, but.. who knows? I stay as far away from that API as possible. ;-) ___ 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] Stacking zope.component registries
On Thursday 08 April 2010, Marius Gedminas wrote: > Someone (I'm bad with names, sorry!) recently proposed a change to > zope.configuration that makes ZCML directives use getSiteManager() > instead of getGlobalSiteManager(); with that patch in, Chris's example > should make ZCML configuration register all the components into your > stacked registry. Although you'd have the other problem of setSite() > having no effect on the site manager, which would break all local > utilities and adapters in your tests. What about using z3c.baseregistry? You can wrap the baseregistry call around your ZCML. This way you can create on registry per layer and then use the __bases__ attribute to stack them together. Regards. Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ 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] Stacking zope.component registries
On Thu, Apr 08, 2010 at 02:37:33PM -0400, Chris McDonough wrote:
> Not sure how a new layer setup and teardown is signaled but assuming you can
> hook that, do something like this:
>
> class StackManager(object):
> def __init__(self, default=None):
> self.stack = []
> self.default = default
>
> def push(self, info):
> self.stack.append(info)
>
> def pop(self):
> if self.stack:
> return self.stack.pop()
>
> def get(self):
> try:
> return self.stack[-1]
> except IndexError:
> return self.default()
>
> def clear(self):
> self.stack[:] = []
>
> from zope.component import getGlobalSiteManager
> global_registry = getGlobalSiteManager()
>
> def defaults():
> return {'registry':global_registry}
>
> manager = StackManager(default=defaults)
>
> def get_current_registry(context=None):
> return manager.get()['registry']
>
> from zope.component import getSiteManager
> getSiteManager.sethook(get_current_registry)
That seems a bit short-sighted: it would break all tests that rely on
setSite() working.
>
> Then when a layer is pushed:
>
>from zope.comonent.registry import Components
>manager.push({'registry':Components()})
I suspect Martin wants
manager.push({'registry': Components(bases=[manager.get()])})
here.
>
> And popped:
>
>manager.pop()
>
>
> On 4/8/10 1:26 PM, Martin Aspeli wrote:
> > Hi,
> >
> > I'd like to come up with a way to set up a test fixture that does the
> > component registry equivalent of stackable DemoStorage's: whilst a layer
> > is in effect, calls to provideAdapter() and friends (and ZCML execution)
> > go into a global registry that is stacked on top of the default global one.o
Someone (I'm bad with names, sorry!) recently proposed a change to
zope.configuration that makes ZCML directives use getSiteManager()
instead of getGlobalSiteManager(); with that patch in, Chris's example
should make ZCML configuration register all the components into your
stacked registry. Although you'd have the other problem of setSite()
having no effect on the site manager, which would break all local
utilities and adapters in your tests.
provideAdapter is harder, since it hardcodes the global registry. You'd
have to monkey-patch the `base` global, or fix provideAdapter and
friends.
> >
> > On layer tear-down, the registry is popped, leaving the original (or
> > previous) global registry intact.
I like this goal.
> >
> > In zope.component.globalregistry, I see:
> >
> > def provideUtility(component, provides=None, name=u''):
> > base.registerUtility(component, provides, name, event=False)
> >
> > base is a module-level variable of type BaseGlobalComponents(). I guess
> > there'd be a way to use __bases__ to create this kind of stack, but I'm
> > not clear on the details, and in particular whether this would really
> > work with provideAdapter() and the rest of the (test-oriented) Python API.
I don't see any way around monkey-patching
zope.component.globalregistry.base/globalSiteManager (two names for the
same object for extra fun!). Also note that the root folder in the
database has a local site manager with __bases__ directly referencing
the global site object, which is pickled by name. If you replace it,
you'll need to use a different BaseGlobalComponents instance, I think.
Marius Gedminas
--
http://pov.lt/ -- Zope 3 consulting and development
signature.asc
Description: Digital signature
___
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] Repository policy testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On Thu, Apr 8, 2010 at 1:13 PM, Tres Seaver wrote: >> I expect to see the list of flagged projects drop significantly on the >> next run. > > Is this list available somewhere for us to review? Current status is posted to the the zope-tests list, e.g.: https://mail.zope.org/pipermail/zope-tests/2010-April/ which posts a daily summary to this list. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAku+N1kACgkQ+gerLs4ltQ4m6ACfRU49HorbhsN/XYbzCR0WjIrd FMQAn3w2Lw1z/XTwgUmy/iGbyyjTOyqr =KMzU -END PGP SIGNATURE- ___ 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] Repository policy testing
On Thu, Apr 8, 2010 at 1:13 PM, Tres Seaver wrote: > I expect to see the list of flagged projects drop significantly on the > next run. Is this list available somewhere for us to review? -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] env var support for zc.buildout
On Thu, Apr 08, 2010 at 04:45:30PM +0200, Adam GROSZER wrote: > Maybe you should take a look at keas.build. > Tho not repo based, but solves such "almost identical sites" cases. I will take a look into it, but for my use case it seems overkill and depends on svn, without support for git. -- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgphiyhJdcnhB.pgp Description: PGP signature ___ 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] Repository policy testing
On 04/08/2010 07:13 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Christian Theune wrote: >> On 04/07/2010 05:44 PM, Tres Seaver wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> I woul like for the checkouts made to test repository policy should use >>> the '--ignore-externals' flag, because the code brought in as externals >>> is either checked separately, or else corresponds to a (non-checked) tag. >> >> Done. > > Thank you! I hadn't realized that the bit doing the checkouts was in > the same package, or I would have added that myself. No worries. The subvertpy API is ... uh ... I'm reading C code to figure it out. :) > BTW, I made another change today to the checker script to avoid > generating spurious failures for packages which have 'setup_requires'. > I also went back through and finished the cleanups I had started, > including branches and adding generated-but-overlooked files. > > I expect to see the list of flagged projects drop significantly on the > next run. Yay, cool. :) -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] Stacking zope.component registries
Not sure how a new layer setup and teardown is signaled but assuming you can
hook that, do something like this:
class StackManager(object):
def __init__(self, default=None):
self.stack = []
self.default = default
def push(self, info):
self.stack.append(info)
def pop(self):
if self.stack:
return self.stack.pop()
def get(self):
try:
return self.stack[-1]
except IndexError:
return self.default()
def clear(self):
self.stack[:] = []
from zope.component import getGlobalSiteManager
global_registry = getGlobalSiteManager()
def defaults():
return {'registry':global_registry}
manager = StackManager(default=defaults)
def get_current_registry(context=None):
return manager.get()['registry']
from zope.component import getSiteManager
getSiteManager.sethook(get_current_registry)
Then when a layer is pushed:
from zope.comonent.registry import Components
manager.push({'registry':Components()})
And popped:
manager.pop()
On 4/8/10 1:26 PM, Martin Aspeli wrote:
> Hi,
>
> I'd like to come up with a way to set up a test fixture that does the
> component registry equivalent of stackable DemoStorage's: whilst a layer
> is in effect, calls to provideAdapter() and friends (and ZCML execution)
> go into a global registry that is stacked on top of the default global one.
>
> On layer tear-down, the registry is popped, leaving the original (or
> previous) global registry intact.
>
> In zope.component.globalregistry, I see:
>
> def provideUtility(component, provides=None, name=u''):
> base.registerUtility(component, provides, name, event=False)
>
> base is a module-level variable of type BaseGlobalComponents(). I guess
> there'd be a way to use __bases__ to create this kind of stack, but I'm
> not clear on the details, and in particular whether this would really
> work with provideAdapter() and the rest of the (test-oriented) Python API.
>
> Martin
>
> ___
> 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 )
>
--
Chris McDonough
Agendaless Consulting, Fredericksburg VA
The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book
___
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] "Comply with repository policy" ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > I've seen lots of checkins recently stating "Comply with repository policy". > > I haven't seen any announcement of a new official repository policy. > Have I missed it? > > I'd be especially interested who exactly is responsible for changing > code so that it complies with the new policy. How much of the initial > work is automated and taken care of by some small group of people and > what is left to the individual package maintainers? How are packages > without maintainers handled? What about trunk vs. old branches? The testing for compliance and the automated part of the fixups are maintained in the 'zope.repositorypolicy' project: http://svn.zope.org/zope.repositorypolicy/trunk There is a nightly test run which checks out all top-level projects and verifies conformance (using the checker) against each projects "trunk" and "release branches." Projects which flunk that check show up on the "shame list" mailed to the zope-tests test aggregator, e.g.: https://mail.zope.org/pipermail/zope-tests/2010-April/013877.html That script ignores tags (we aren't rewriting history), as well as branches whose names don't look "release-like". I have been using the checker / fixer to get projects I feel responsibility for into complieance with the policy. The process normally involves: - Check out the project (easiest to do the whole tree). $ svn co $ZSVN/myproject - In the trunk and each "release" branch: o Run the checker script, e.g.:: $ cd myproject/trunk $ /path/to/zrp/bin/zope-org-check-project . ... ... o Run the automated fixups:: $ /path/to/zrp/bin/zope-org-fix-project . ... ... o Find and fix anything the automated fixer couldn't handle. I nearly always have to fix up the 'author' in setup.py, for instance.: # Repeat until the checker runs clean $ /path/to/zrp/bin/zope-org-check-project . ... ... $ gvim setup.py # fix 'author', etc. o Add any files created by the fixer:: $ svn add LICENSE.txt COPYRIGHT.txt Repeat in each of the "release" branches, then check it all in: $ cd .. $ svn commit -m "Comply with repository policy." My theory is that I will clean up the stuff I care about, and others will clean up the stuff they care about. The stuff which stays on the "shame list" can be identified cleanly as "unmaintained." We can figure out what to do about them after some time period has elapsed. Note that I pulled one project (Zelenium) out of the repository altogether, because it contained third-party code I couldn't relicense to the ZPL: I moved its trunk over to Launchpad, and left only a stub behind in the zope.org SVN. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAku+FNkACgkQ+gerLs4ltQ5WeACfUikaZKiJsbIoJ3UJ4a14PVQz K6sAoIlyzbnhdOZUu2uK5qKFTmYA75hc =GdR8 -END PGP SIGNATURE- ___ 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 )
[Zope-dev] Stacking zope.component registries
Hi, I'd like to come up with a way to set up a test fixture that does the component registry equivalent of stackable DemoStorage's: whilst a layer is in effect, calls to provideAdapter() and friends (and ZCML execution) go into a global registry that is stacked on top of the default global one. On layer tear-down, the registry is popped, leaving the original (or previous) global registry intact. In zope.component.globalregistry, I see: def provideUtility(component, provides=None, name=u''): base.registerUtility(component, provides, name, event=False) base is a module-level variable of type BaseGlobalComponents(). I guess there'd be a way to use __bases__ to create this kind of stack, but I'm not clear on the details, and in particular whether this would really work with provideAdapter() and the rest of the (test-oriented) Python API. Martin ___ 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] Repository policy testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > On 04/07/2010 05:44 PM, Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I woul like for the checkouts made to test repository policy should use >> the '--ignore-externals' flag, because the code brought in as externals >> is either checked separately, or else corresponds to a (non-checked) tag. > > Done. Thank you! I hadn't realized that the bit doing the checkouts was in the same package, or I would have added that myself. BTW, I made another change today to the checker script to avoid generating spurious failures for packages which have 'setup_requires'. I also went back through and finished the cleanups I had started, including branches and adding generated-but-overlooked files. I expect to see the list of flagged projects drop significantly on the next run. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAku+DscACgkQ+gerLs4ltQ6F0gCghJ+3N0x+4ZkeQopEyBREydEi cpMAn2Va+q6Dx6eUfpAZhdtdtdT+EzwW =3Gtw -END PGP SIGNATURE- ___ 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 )
[Zope-dev] "Comply with repository policy" ?
Hi. I've seen lots of checkins recently stating "Comply with repository policy". I haven't seen any announcement of a new official repository policy. Have I missed it? I'd be especially interested who exactly is responsible for changing code so that it complies with the new policy. How much of the initial work is automated and taken care of by some small group of people and what is left to the individual package maintainers? How are packages without maintainers handled? What about trunk vs. old branches? Thanks, Hanno ___ 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 )
[Zope-dev] Retire zope3-checkins list
Hi, What about retiring zope3-checkins list ? Regards, Baiju M ___ 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] env var support for zc.buildout
Hello Florian, Thursday, April 8, 2010, 3:32:22 PM, you wrote: ... FF> We currently use it for 5 very similar sites that share one repository FF> but use 5 checkouts of it: Maybe you should take a look at keas.build. Tho not repo based, but solves such "almost identical sites" cases. -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: One of the things that distinguishes man from the other animals is that he wants to know things, wants to find out what reality is like, simply for the sake of knowing. When that desire is completely quenched in anyone, I think he has become less than human. - C.S. Lewis ___ 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] env var support for zc.buildout
On Thu, Apr 08, 2010 at 09:01:58AM -0400, Jim Fulton wrote: > On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote: > > I wonder what Jim thinks about the topic. > > I have mixed feelings. Accessing environment variables seems > reasonable on some level, however: > > - I'd worry about the choice of the virtual section name. "env" or > "environment" seems too likely to break existing buildouts. > > - I worry a bit about making buildout's "programming language" > even more sophisticated. > > Florian, can you describe why you want to use environment variables in > extends? The mail written during lunchtime made it out before I read this one... -- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpGXhmMsnbP6.pgp Description: PGP signature ___ 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] env var support for zc.buildout
On Thu, Apr 08, 2010 at 02:24:53PM +0200, Christian Theune wrote:
> Hi,
>
> On 04/08/2010 12:59 PM, Florian Friesdorf wrote:
> > On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
> >> On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
> >>> environment variable support for zc.buildout, including extends!
> >>>
> >>> https://bugs.launchpad.net/zc.buildout/+bug/557769
> >>>
> >>> works for me so far
>
> Actually the env recipe was more of a hack to get going and then we
> forgot to propose getting it into buildout.
>
> OTOH handling it as a recipe allows for some other nice tricks, e.g.
> overriding by extensions.
>
> Maybe a specialised part-name, like versions would be helpful so that
> buildout could pre-populate that part during initialisation and then
> allow configurations to override individual values.
that would be nice indeed, but again would not work for extends
We currently use it for 5 very similar sites that share one repository
but use 5 checkouts of it:
base.cfg
[buildout]
parts = instance
develop = ...
eggs = ...
zcml = ...
[instance]
...
site-1.cfg
[buildout]
eggs +=
zcml +=
testenv.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
deploy.cfg
[buildout]
extends =
base.cfg
${env:site}.cfg
% site=site-1 ./bin/buildout -c deploy.cfg
> On your specific patch: you sure about that direct regex match for the
> expanding variables in the extends option?
I'd prefer using the logic from Options, but that relies on
self.buildout being an actual buildout already. I patched that up and
actually succeeded to use Options for extends, but had some failing
tests.
The direct regex is only used at _open-time on extends.
The only thing coming to my mind, why one would avoid a direct regex, is
performance and the performance penalty should be minimal like that.
However, I'm happy to be told different.
> I wonder what Jim thinks about the topic.
me too
> >> Uhm ... interesting. I never noticed our recipe not to work with
> >> extends. Can you give me an example?
> >
> > actually, i just assumed from looking at buildout.py - extends is
> > processed before the whole Buildout ist up. As far as I understand your
> > recipe is not even loaded when buildout would need that variable lookup.
> >
> > But, I saw you recipe after I implemented and never tried it...
>
> I just played with that scenario. Something that doesn't work with our
> recipe:
>
> a.cfg:
> [buildout]
> parts = x
>
>
> [x]
> recipe = zc.recipe.egg
> eggs = zope.interface
> foo = ${env:bar}
>
> buildout.cfg:
> [buildout]
> extends = a.cfg
>
>
> [env]
> recipe = gocept.recipe.env
In the tests contained in the patches are even more sophisticated
scenarios :)
--
Florian Friesdorf
GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367
Jabber/XMPP: f...@chaoflow.net
OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700
IRC: chaoflow on freenode,ircnet,blafasel,OFTC
pgpuqLKskApSf.pgp
Description: PGP signature
___
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] env var support for zc.buildout
On Thu, Apr 8, 2010 at 9:05 AM, Christian Theune wrote: ... > Can you use any variable expansion in the values given in the [buildout] > section anyway? Only in a limited way that isn't well defined. :) Probably, you can't use expansion for options that are used early -- before the substitutions are performed. Jim -- Jim Fulton ___ 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] env var support for zc.buildout
On 04/08/2010 03:10 PM, Fred Drake wrote: On Thu, Apr 8, 2010 at 9:03 AM, Christian Theune wrote: The "special" that I was referring to was the fact that you don't have to spell a recipe name for that section (like the buildout section). There are many times you can have a section that isn't a part; the buildout section is just that, as is the section named by buildout:versions. Only parts need to have the recipe specified. *If* buildout should support some special "environment" section, I'd hope that it was explicitly referenced by something like buildout:environment. This would avoid the problem of breaking existing buildouts that already use sections with whatever conventional name arises for this feature. Fullack. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ 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] short svn.zope.org downtime
On 04/08/2010 03:12 PM, Jim Fulton wrote: On Thu, Apr 8, 2010 at 2:59 AM, Christian Theune wrote: On 04/07/2010 05:14 PM, Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/7/10 17:08 , Tres Seaver wrote: I'm seeing frequent periods of 50+% packet loss to the machine, and can't even get top to run on it this morning. Any clues about what is causing the load? I haven't watched it because I don't know when Theuni has set that particular cron job, but I bet the whole repository policy checker is causing a lot of load. The checker runs at 2:15 CE(ST) for about 90 minutes. However, the script only loads recent revisions and does the working copy checkouts step by step instead of a large run, so I don't think it is aggressive enough to cause troubles. (Can't be sure of course.) Is it running against the main repo? or a mirror? Its running against the main repo - we currently don't have a mirror around, but I'll have one again in the next weeks so if it should be an issue I can relocate that in the future. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ 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] short svn.zope.org downtime
On Thu, Apr 8, 2010 at 2:59 AM, Christian Theune wrote: > On 04/07/2010 05:14 PM, Jens Vagelpohl wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 4/7/10 17:08 , Tres Seaver wrote: >> >>> I'm seeing frequent periods of 50+% packet loss to the machine, and >>> can't even get top to run on it this morning. Any clues about what is >>> causing the load? >> >> I haven't watched it because I don't know when Theuni has set that >> particular cron job, but I bet the whole repository policy checker is >> causing a lot of load. > > The checker runs at 2:15 CE(ST) for about 90 minutes. However, the > script only loads recent revisions and does the working copy checkouts > step by step instead of a large run, so I don't think it is aggressive > enough to cause troubles. (Can't be sure of course.) Is it running against the main repo? or a mirror? Jim -- Jim Fulton ___ 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] env var support for zc.buildout
On Thu, Apr 8, 2010 at 9:03 AM, Christian Theune wrote: > The "special" that I was referring to was the fact that you don't have to > spell a recipe name for that section (like the buildout section). There are many times you can have a section that isn't a part; the buildout section is just that, as is the section named by buildout:versions. Only parts need to have the recipe specified. *If* buildout should support some special "environment" section, I'd hope that it was explicitly referenced by something like buildout:environment. This would avoid the problem of breaking existing buildouts that already use sections with whatever conventional name arises for this feature. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] env var support for zc.buildout
On 04/08/2010 03:01 PM, Jim Fulton wrote: On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote: I wonder what Jim thinks about the topic. I have mixed feelings. Accessing environment variables seems reasonable on some level, however: - I'd worry about the choice of the virtual section name. "env" or "environment" seems too likely to break existing buildouts. - I worry a bit about making buildout's "programming language" even more sophisticated. Though so - same mixed feelings over here. :) Florian, can you describe why you want to use environment variables in extends? The general reason I can see is "it works everywhere else", except that there's some bootstrapping problem involved at some point anyway. Can you use any variable expansion in the values given in the [buildout] section anyway? Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ 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] env var support for zc.buildout
On 04/08/2010 02:57 PM, Fred Drake wrote: On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote: Maybe a specialised part-name, like versions would be helpful so that buildout could pre-populate that part during initialisation and then allow configurations to override individual values. It's probably worth mentioning that "versions" isn't a specialized part name in any sense; the name has to be explicitly mentioned in buildout:versions, and could be named anything. The use of explicit section references instead of a lot of "magic" section names is a good thing about buildout. Yup. The "special" that I was referring to was the fact that you don't have to spell a recipe name for that section (like the buildout section). Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ 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] env var support for zc.buildout
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote: > I wonder what Jim thinks about the topic. I have mixed feelings. Accessing environment variables seems reasonable on some level, however: - I'd worry about the choice of the virtual section name. "env" or "environment" seems too likely to break existing buildouts. - I worry a bit about making buildout's "programming language" even more sophisticated. Florian, can you describe why you want to use environment variables in extends? Jim -- Jim Fulton ___ 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] env var support for zc.buildout
On Thu, Apr 8, 2010 at 8:24 AM, Christian Theune wrote: > Maybe a specialised part-name, like versions would be helpful so that > buildout could pre-populate that part during initialisation and then > allow configurations to override individual values. It's probably worth mentioning that "versions" isn't a specialized part name in any sense; the name has to be explicitly mentioned in buildout:versions, and could be named anything. The use of explicit section references instead of a lot of "magic" section names is a good thing about buildout. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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] env var support for zc.buildout
Hi,
On 04/08/2010 12:59 PM, Florian Friesdorf wrote:
> On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote:
>> On 04/08/2010 04:27 AM, Florian Friesdorf wrote:
>>> environment variable support for zc.buildout, including extends!
>>>
>>> https://bugs.launchpad.net/zc.buildout/+bug/557769
>>>
>>> works for me so far
Actually the env recipe was more of a hack to get going and then we
forgot to propose getting it into buildout.
OTOH handling it as a recipe allows for some other nice tricks, e.g.
overriding by extensions.
Maybe a specialised part-name, like versions would be helpful so that
buildout could pre-populate that part during initialisation and then
allow configurations to override individual values.
On your specific patch: you sure about that direct regex match for the
expanding variables in the extends option?
I wonder what Jim thinks about the topic.
>> Uhm ... interesting. I never noticed our recipe not to work with
>> extends. Can you give me an example?
>
> actually, i just assumed from looking at buildout.py - extends is
> processed before the whole Buildout ist up. As far as I understand your
> recipe is not even loaded when buildout would need that variable lookup.
>
> But, I saw you recipe after I implemented and never tried it...
I just played with that scenario. Something that doesn't work with our
recipe:
a.cfg:
[buildout]
parts = x
[x]
recipe = zc.recipe.egg
eggs = zope.interface
foo = ${env:bar}
buildout.cfg:
[buildout]
extends = a.cfg
[env]
recipe = gocept.recipe.env
--
Christian Theune · c...@gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
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 )
[Zope-dev] Zope Tests: 6 OK, 1 Failed
Summary of messages to the zope-tests list. Period Wed Apr 7 12:00:00 2010 UTC to Thu Apr 8 12:00:00 2010 UTC. There were 7 messages: 6 from Zope Tests, 1 from ct at gocept.com. Test failures - Subject: FAILED: Repository policy check found errors in 697 projects From: ct at gocept.com Date: Wed Apr 7 21:11:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013877.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Apr 7 21:29:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013878.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Apr 7 21:31:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013879.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Apr 7 21:33:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013880.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Apr 7 21:35:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013881.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Apr 7 21:37:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013882.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Apr 7 21:39:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013883.html ___ 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] env var support for zc.buildout
On Thu, Apr 08, 2010 at 08:56:18AM +0200, Christian Theune wrote: > On 04/08/2010 04:27 AM, Florian Friesdorf wrote: > > environment variable support for zc.buildout, including extends! > > > > https://bugs.launchpad.net/zc.buildout/+bug/557769 > > > > works for me so far > > Uhm ... interesting. I never noticed our recipe not to work with > extends. Can you give me an example? actually, i just assumed from looking at buildout.py - extends is processed before the whole Buildout ist up. As far as I understand your recipe is not even loaded when buildout would need that variable lookup. But, I saw you recipe after I implemented and never tried it... -- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: f...@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp8gyGAw8Rvy.pgp Description: PGP signature ___ 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 )
