- Zope-Dev - Zope lists

Re: [Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
by Michael Howitz 15 May '09

15 May '09

Am 15.05.2009 um 05:32 schrieb Chris McDonough: > Log message for revision 99961: > - Remove a dependency on ``zope.container.contained.Contained`` > (this is a dumb base class that defines __parent__ and __name__ > as None and declares that the class implements IContained). What's the reason behind this refactoring? Instead of zope.container.contained.Contained the IntIds class now depends on zope.container.interface.IContained plus it redefines the things which are already defined in zope.container.contained.Contained. I do not see why this is better than using the base class. > Changed: > U zope.intid/trunk/CHANGES.txt > U zope.intid/trunk/src/zope/intid/__init__.py [...] > Modified: zope.intid/trunk/src/zope/intid/__init__.py > ===================================================== > --- zope.intid/trunk/src/zope/intid/__init__.py 2009-05-15 02:41:49 > UTC (rev 99960) > +++ zope.intid/trunk/src/zope/intid/__init__.py 2009-05-15 03:31:59 > UTC (rev 99961) > @@ -24,10 +24,9 @@ > > import BTrees > from persistent import Persistent > -from ZODB.interfaces import IConnection > from zope.component import adapter, getAllUtilitiesRegisteredFor, > subscribers > from zope.container.interfaces import IObjectAddedEvent, > IObjectRemovedEvent > -from zope.container.contained import Contained > +from zope.container.interfaces import IContained > from zope.event import notify > from zope.interface import implements > from zope.keyreference.interfaces import IKeyReference, NotYet > @@ -37,14 +36,16 @@ > from zope.intid.interfaces import IIntIds, IIntIdEvent > from zope.intid.interfaces import IntIdAddedEvent, IntIdRemovedEvent > > -class IntIds(Persistent, Contained): > +class IntIds(Persistent): > """This utility provides a two way mapping between objects and > integer ids. > > IKeyReferences to objects are stored in the indexes. > """ > - implements(IIntIds) > + implements(IIntIds, IContained) > > + __parent__ = __name__ = None > + > _v_nextid = None Yours sincerely, -- Michael Howitz · mh(a)gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development

6 8

Zope Tests: 8 OK
by Zope Tests Summarizer 15 May '09

15 May '09

Summary of messages to the zope-tests list. Period Thu May 14 12:00:00 2009 UTC to Fri May 15 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 20:54:45 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011707.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 20:57:05 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011708.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 20:59:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011709.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu May 14 21:01:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011710.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Thu May 14 21:03:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011711.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu May 14 21:05:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011712.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu May 14 21:07:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011713.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Thu May 14 21:09:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011714.html

1 0

z3c.recipe.i18n tests break on unix
by Christian Zagrodnick 15 May '09

15 May '09

Hi, the tests of z3c.reipce.i18n break on unix systems, for instance with: Failed example: ls('bin') Expected: - buildout-script.py - buildout.exe - i18ncompile-script.py - i18ncompile.exe - i18nextract-script.py - i18nextract.exe - i18nmergeall-script.py - i18nmergeall.exe - i18nstats-script.py - i18nstats.exe Got: - buildout - i18ncompile - i18nextract - i18nmergeall - i18nstats What's the general way of testing those things in both environments? I don't have a windows box to test this. I also see most recipes are tested only for unix (which would be fine for me). How should we proceed in this special case? Actually there is a bug which I'm going to fix w/o having passing tests now. Regards, -- Christian Zagrodnick · cz(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development

3 4

"ZTK" futures: one big package?
by Chris McDonough 14 May '09

14 May '09

I was just thinking about the future of the "ZTK", and in the past I have argued for not attempting to version the entire set of packages that currently comprises Zope 3 over time as "ZTK releases". Instead, I have argued for promoting packages that have some life of their own (independent of the rest of the pile) into subprojects that have their own release cycles. Then outside projects such as Plone and Grok could depend on independent versions of such packages, giving them slightly more flexibility than requiring a "version of the ZTK". Given that this suggestion has been met with skepticism, let me try another tact. Instead of thinking about it this way, could we think about it as *deflating* the current set of zope.* packages that do not currently have a meaningful life of their own into a single setuptools distribution named "ZTK". This package would include most everything in zope.app*, plus things like zope.server, zope.publisher, and other things that just aren't useful outside of Zope-the-appserver, or which currently just depend on "too much". This "ZTK" distribution would *not* include packages that already have a life of their own outside Zope such as zope.interface, zope.component, zope.configuration, zope.proxy, ZODB, etc. These packages would continue to have their own release cycles. Over time, we'd tease out the dependencies of packages that live in the ZTK distribution, making them useful outside without any dependency on the ZTK. The names of these packages could be arbitrary (they wouldn't need to retain their old "zope.*" names). Some backwards dependency shims would be added to the ZTK to prevent old imports from breaking, and the ZTK distribution would then just have a dependency on the thing that got broken out. I'm thinking that this would simplify things greatly for people who want to be consumers of "truly independent" Zope packages. There'd be exactly N of them available for download (where N is much less than 100, more like 20), plus the ZTK, which would have the rest of the pile in it over time. If someone wanted to use a forked version of a package that lived in the ZTK distribution, they'd either do so by teasing out the dependencies and making it "truly independent" or they'd just reroll a custom version of the entire ZTK distribution. Does this make any sense? - C - C

11 40

Zope Tests: 8 OK
by Zope Tests Summarizer 14 May '09

14 May '09

Summary of messages to the zope-tests list. Period Wed May 13 12:00:00 2009 UTC to Thu May 14 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed May 13 20:51:45 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011699.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed May 13 20:53:46 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011700.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Wed May 13 20:55:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011701.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Wed May 13 20:57:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011702.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Wed May 13 20:59:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011703.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed May 13 21:01:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011704.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Wed May 13 21:03:47 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011705.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Wed May 13 21:05:48 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011706.html

1 0

reusability markers in our documentation
by Martijn Faassen 13 May '09

13 May '09

Hi there, In the "ZTK futures" thread Chris McDonough pointed out that right now we don't signal which packages are easily reusable outside of the Zope Toolkit and which packages aren't, and need a great knowledge of the way the Zope Toolkit works and a large amount of installed packages. In order to increase our focus on reusable packages that stand on their own, and to reduce confusion by the outside world, we should signal clearly which packages should be considered by the broader community, and more importantly, which packages they can safely ignore. I've therefore created the following guideline in the Zope Toolkit decisions document: Some Zope Toolkit packages are quite reusable without having to buy into the rest of the Zope Toolkit. Others aren't reusable at all without pulling in a huge chunk of the Zope Toolkit; they depend on many assumptions. We should communicate this clearly to potential users. As a first step, we will make sure these notifications are available on the PyPI pages. We will do this by adding a message about reusability to the long_description (which gets displayed on PyPI). Typically this is done by modifying the package's README.txt or ``src/zope/../README.txt`` doctest. The following text should be used for reusable packages:: *This package is intended to be independently reusable in any Python project. It is maintained by the* `Zope Toolkit project <http://docs.zope.org/zopetoolkit/>`_. The following text should be used for packages that are *not* easily reusable:: *This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the* `Zope Toolkit project <http://docs.zope.org/zopetoolkit/>`_. At the time of writing, most of our packages will be marked as *not* reusable. Only packages at the roots of our dependency tree that have a clear purpose and some documentation (such as ``zope.interface`` and ``zope.component``) should be marked as reusable. We will slowly start to build up from there. Help is needed to mark these packages. As a safe assumption, all zope.app.* packages should be marked as not reusable. It's a simple matter of going to the setup.py, seeing what file ends up being the start of long_description (typically README.txt or something like that) and modifying it with the marker text. I've marked zope.component, zope.interface and zope.schema as "reusable". That doesn't mean their documentation shouldn't be improved to support this; it should. But nevertheless it's pretty doable to reuse them today. We have more such packages; in case of any doubt about the status, please bring it up in discussions here. I've marked zope.app.publication as not reusable already. Volunteers to help mark the other packages? Regards, Martijn

1 0

Re: [Zope-dev] Mailinglist for Zope 2 bug!?
by Sidnei da Silva 13 May '09

13 May '09

On Wed, May 13, 2009 at 11:46 AM, Andreas Jung <andreas(a)andreas-jung.com> wrote: > So anyone can subscribe to Zope 2 ticket changes without having > to be a member of the Zope 2 team. Works for me. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com

1 0

Zope Tests: 8 OK
by Zope Tests Summarizer 13 May '09

13 May '09

Summary of messages to the zope-tests list. Period Tue May 12 12:00:00 2009 UTC to Wed May 13 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 20:52:26 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011691.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 20:54:28 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011692.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 20:56:29 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011693.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Tue May 12 20:58:29 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011694.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Tue May 12 21:00:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011695.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 21:02:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011696.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Tue May 12 21:04:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011697.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Tue May 12 21:06:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011698.html

1 0

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Chris Withers 13 May '09

13 May '09

Andreas Jung wrote: >> - It's being done into the beta phase of Zope 2.12 > changes in this *early* beta phase, no changes after beta 2 are > acceptable). This feels like an abuse of your position as release manager. Can you honestly tell me that if it was anyone other than you, you'd let them merge these changes after you'd already cut beta 1? > Feature 2 (the one you are complaining about): Making <environment> a > multisection. > > The rational behind this change is clear: making the Zope configuration > more modular for bigger setups. In complex setups there is a need for > having this > extension if you don't want and can't to build a monolithic configuration. There are plenty of options other than this, the one that jumps to mind would be a buildout recipe similar to collective.recipe.template that staples together your various config file snippets into one zope.conf. > "The community" working on Zope 2.12 was basically Hanno doing most of > the work, > Tres and me. That's not quite true, other people have been contributing fixes and I know I spent a lot of time getting Zope 2.12 to work in a buildout without the need for rewriting the zope2instance recipe. But, that aside, people working on Zope 2.12 does not make up the whole community, there's the whole userbase, or even potential userbase to consider. > So the actual development is driven by the people doing the > work and by > their needs. I agree with this. > Not every new feature must be discussed in depth on the list. I don't agree with this. New features should always be discussed. Had you posted the messages you posted to the bug tracker to this list instead, and then waited a week or so for people to comment, that would have been fine. The problem is that the visibility of issues in Launchpad is very poor. You can't even get notifications of bugs unless you're part of the development team. Using it for features means that no-one in the wider community is likely to even know what's going on. That's bad as it means that no-one gets the opportunity to make suggestions or comments. This could be improved by getting issue emails sent to this list too, is that possible? > Consider this being a defect of your release process and planning. *My* release process and planning? > We are running this stuff in production at Haufe on *very*very*very* > large sites. > All those changes are the result of using Zope in enterprise-level > installations. > I don't know many other Zope installation that beat our internal and > external setups > in size and complexity. Glad to hear it, I was also glad to hear about the tools that make use of these events being released. I look forward to it :-) > The primary purpose of the <environment> section is for making > additional environment > variables available with Zope. I consider being an "internal" > functionality. Well, I consider it less than internal ;-) >> Andreas, please revert this change until people have had a chance to >> look at it properly. > Reverting the change without a discussion was offending (see above). And > I want to emphasize > once more: none of the people doing the development work need to ask for > every single > change made to the Zope 2 core for public feedback. I actually agree with this, but I don't agree in the case of new features or in the case of backwards compatibility breakages. Nevertheless, if you're intent on bulldozing this change through, please consider using and writing a test for the one additional like I gave you that should result in getConfiguration().environment being the single dict it always has been and should logically be. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

5 9

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Chris Withers 12 May '09

12 May '09

Andreas Jung wrote: > Every active core developer should be member of Zope 2 dev team: > > https://launchpad.net/~zope2-dev > > It is up to each developer to join the team It took me ages to figure out how to do this, and I still couldn't tell you how to do it now. Launchpad has an *extremely* poor UI here, what would be so hard about having a "request to join this team" link somewhere prominently on the team page? It might be good to put an explanation of how to do this on: http://docs.zope.org/developer/ ...once you figure it out. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 14