- Zope-Dev - Zope lists

explicit sys.path manipulation in test.py causing problems
by Rob Miller 10 Sep '08

10 Sep '08

hi all, in Zope's testrunner, the SOFTWARE_HOME is explicitly added to the front of the python package lookup path, like so: sys.path.insert(0, shome) this doesn't happen in the same manner when you're actually starting a Zope server. as a result, the test runner will not work in certain environments where Zope itself is purring happily along. specifically, i've got a setup where Zope 2.10 is installed into a virtualenv using the traditional Zope install mechanisms. i want to use ZODB BLOB storage, however, so i've got ZODB 3.8 eggs installed. setuptools gives eggs precedence over non-egg packages, so this works well, except when using test.py, where the explicit insertion of SOFTWARE_HOME at the very beginning of sys.path trumps the egg installation. i'd like to put a check in there so that SOFTWARE_HOME is only added to the package lookup if the Zope2 package isn't already available: try: import Zope2 except ImportError: sys.path.insert(0, shome) in other words, if the environment is already set up, don't mess with it. anyone have a problem w/ me making this change on trunk and the 2.10 and 2.11 branches? -r

1 0

Re: [Zope-dev] SVN: z3c.pt/trunk/TODO.txt
by Malthe Borch 10 Sep '08

10 Sep '08

Chris McDonough wrote: > Log message for revision 90974: > Added: z3c.pt/trunk/TODO.txt > =================================================================== > --- z3c.pt/trunk/TODO.txt (rev 0) > +++ z3c.pt/trunk/TODO.txt 2008-09-09 00:03:08 UTC (rev 90974) > @@ -0,0 +1,4 @@ > +- Make e.g. <tal:block tal:foo /> and <metal:foo metal:define-macro/> etc. > + work Are we sure we want this? It's (afaik) not correct XML; but maybe an exception should be raised, rather than no interpretation. \malthe

6 8

Zope Tests: 5 OK
by Zope Tests Summarizer 10 Sep '08

10 Sep '08

Summary of messages to the zope-tests list. Period Tue Sep 9 11:00:00 2008 UTC to Wed Sep 10 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Sep 9 20:53:04 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010140.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 9 20:54:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010141.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 9 20:56:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010142.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 9 20:57:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010143.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Sep 9 20:59:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010144.html

1 0

batching zope.sendmail
by Daniel Widerin 09 Sep '08

09 Sep '08

hi guys i'm out of the plone world and since i'm developing for singing&dancing i would really like to have batching included into zope.sendmail. queuedDelivery does have self.interval which defines time between each queue-run. most mailservers accept only 10 connections at the same time and thats the point why we should think about batching. i've played around with zope.sendmail 3.5 and implemented batching on my testserver. anybody interested for commiting this into a new branch/trunk and have a look at it? saily

2 1

Zope Tests: 5 OK
by Zope Tests Summarizer 09 Sep '08

09 Sep '08

Summary of messages to the zope-tests list. Period Mon Sep 8 11:00:00 2008 UTC to Tue Sep 9 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Mon Sep 8 20:51:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010135.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 8 20:53:01 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010136.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 8 20:54:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010137.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 8 20:56:01 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010138.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 8 20:57:31 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010139.html

1 0

Re: [Zope-dev] nadako declined by philipp-weitershausen
by Stephan Richter 08 Sep '08

08 Sep '08

On Sunday 07 September 2008, Zope 3 Developers wrote: > The membership status of nyo (nadako) in the team Zope 3 Developers > (zope3-dev) was changed by Philipp von Weitershausen (philipp- > weitershausen) from Proposed to Declined. > <https://edge.launchpad.net/~zope3-dev> > > Philipp von Weitershausen said: > Sorry, don't know you. I know him. He is nyo on IRC and his name is Dan Korostelev. He works on z3c.form and z3c.blobfile right now. We should definitely accept him. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"

1 0

Re: [Zope-dev] SVN: z3c.form/trunk/src/z3c/form/browser/README.txt This control sequence is hard to parse and unnecessary.
by Malthe Borch 08 Sep '08

08 Sep '08

Stephan Richter wrote: > I wanted to test that Bytes widgets accept non-ASCII characters, which is the > point of choosing the Bytes over ASCII field. Now, it might very well be that > the produced XML is not valid, in which case we should fix the widget/data > converter. Gotcha; I'll commit a change that tests for a valid non-ASCII character then. \malthe

1 0

Re: [Zope-dev] SVN: z3c.form/trunk/src/z3c/form/browser/README.txt This control sequence is hard to parse and unnecessary.
by Malthe Borch 08 Sep '08

08 Sep '08

Stephan Richter wrote: >> - >>> field = zope.schema.Bytes(default='\10\45\n\32') >> + >>> field = zope.schema.Bytes(default='Default bytes') > > Hey Malthe, you weakened the test a lot by not having non-ASCII characters in > the test now. Why did you troubles with that? The ``xml.parsers.expat`` module claims that the previous value was not valid in an XML document. I think it constitutes some flawed escape sequence, at least according to this module. But that could be a bug. What were you trying to test in particular? \malthe

1 0

Zope Tests: 5 OK
by Zope Tests Summarizer 08 Sep '08

08 Sep '08

Summary of messages to the zope-tests list. Period Sun Sep 7 11:00:00 2008 UTC to Mon Sep 8 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sun Sep 7 20:52:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010130.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sun Sep 7 20:53:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010131.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sun Sep 7 20:55:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010132.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sun Sep 7 20:56:45 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010133.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sun Sep 7 20:58:15 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010134.html

1 0

Dependencies and future of zope 3
by David Pratt 07 Sep '08

07 Sep '08

Hi there. I have been developing with zope3 for about 4 years and would like to see zope continue in a healthy way into the future. The last couple of years particularly have brought significant change in how we deploy zope particularly with wsgi with or without the zodb. In addition, there is a increasing plethora of lightweight frameworks emerging to compete with mind share and feel zope is loosing ground in this respect. I am feeling increasing pressure and frustration to re-examine what I am doing. Zope has a wonderful code base but it is spread through many packages in the form of dependencies. As a result, a small app in a working z3 setup can start off at almost 50MB while the similar app on a competitive framework may be as little as 15 - 20 MB. To some extent, there is complexity in the politics of change needed since zope is largely consumed as packages by z2 (Plone). So the impetus for change may be less than favorable for those consuming packages in Plone as opposed to a developer interested in creating larger scale apps purely from zope 3 and other python packages. The key concern is dependencies. There have been efforts I realize to settle some of this over the past but in reality the volume of zope packages that comed together for a base build is 'pulling in the world' as i have heard it referred to many times. The testing setup is another major factor in this and the changes controversial over the eliminating the testing framework as a dependency of zope eggs. I guess the simple solution is well it you don't like it, use the another framework. Its not quite that simple since I am extremely fond of the CA architecture and have a strong desire to continue with it in some form or another into the future. I think what I am sensing more than anything is a need for zope to adapt a changing reality. bfg is a relatively new framework that builds on wsgi and zope technologies but is an example of what can be achieved if you consume only what you need. It is attractive in a number of respects for zope developers since it offers simplicity and development speed with a lightweight footprint. I believe much of what is being accomplished in bfg could be accomplished in zope if it were tighter and we could focus on a leaner core of packages void of the large number of dependencies. The grokcore packages can help with the simplicity development but do little for the dependency issues. I think there are couple of options. One option would be to set about on a course of change to do something about this with the existing codebase. Another option is to create a core of leaner packages that could result in a much smaller, tighter core that can be competitive with the changing python landscape. bfg is currently taking the option of selectively forking some of the packages such as zope.catalog as repoze.catalog for example. Personally, I would like to see these changes occur in some way within zope. In any case I am interested in hearing from folks about what can or ought to be done or whether there is interest in this direction. Many thanks. Regards David

18 48