Re: [Zope-dev] Dependencies and future of zope 3
--On 3. September 2008 08:04:00 +0200 Lennart Regebro <[EMAIL PROTECTED]> wrote: On Wed, Sep 3, 2008 at 02:54, David Pratt <[EMAIL PROTECTED]> wrote: 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. That the packages are too dependent on each other today, and that this means a base installation of Zope3 is too big is well known. So I think I can definitely say "Yes" to that answer. This is a big issue? I don't think so. Disks are cheap and usually you don't get in touch with the dependent modules under the hood - except for debugging :-) -aj pgpxtUxyMr9Bj.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependencies and future of zope 3
On Wed, Sep 3, 2008 at 02:54, David Pratt <[EMAIL PROTECTED]> wrote: > 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. That the packages are too dependent on each other today, and that this means a base installation of Zope3 is too big is well known. So I think I can definitely say "Yes" to that answer. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Dependencies and future of zope 3
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
On Tuesday 02 September 2008, Martin Aspeli wrote: > > Some people who use zope.interface reply on being able to singly adapt > > tuples > > I've heard this before, but I've always been curious: why? when is this > a pattern you'd want to use? Ask the twisted guys. :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
Jim Fulton wrote: > Some people who use zope.interface reply on being able to singly adapt > tuples I've heard this before, but I've always been curious: why? when is this a pattern you'd want to use? 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 http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
Hi Jim, Stephan > Betreff: Re: [Zope-dev] Make simple ISource usable > > On Tuesday 02 September 2008, Jim Fulton wrote: > > > An alternative to Roger's proposal would be to move the ITerms > > > declaration and any possible generic implementation of > such into its > > > own package zope.terms. > > > > I don't have a problem with that. :) > > That's what I thought. Impasse resolved? :-) Yeah, this sounds very good to me. I'll pick that up next week and implement this part in a branch for review. Regards Roger Ineichen > Regards, > Stephan > -- > Stephan Richter > Web Software Design, Development and Training Google me. > "Zope Stephan Richter" > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
On Tuesday 02 September 2008, Jim Fulton wrote: > > An alternative to Roger's proposal would be to move the ITerms > > declaration and > > any possible generic implementation of such into its own package > > zope.terms. > > I don't have a problem with that. :) That's what I thought. Impasse resolved? :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
On Sep 2, 2008, at 10:38 AM, Stephan Richter wrote: > On Tuesday 02 September 2008, Jim Fulton wrote: >>> This whould not affect other implementations like >>> the ISourceQueriables etc. It only offers the >>> a way to implement reusable simple ISource components >>> without the need that every UI framework needs to >>> implement their own interfaces for query ISource >>> component in their own way (e.g. ITerms). >> >> Why can't they use zope.app.form.interfaces.ITerms > > Because it makes every project that uses sources in a meaningful way > depend on > zope.app.form, which has a lot of dependencies that I do not want. It > prohibits another form framework, such as z3c.form to not depend on > zope.app.form, which suck to say the least. :-) > > An alternative to Roger's proposal would be to move the ITerms > declaration and > any possible generic implementation of such into its own package > zope.terms. I don't have a problem with that. :) Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component: calling an Interface and calling queryAdapter give differing results
On Sep 1, 2008, at 12:33 PM, Philipp von Weitershausen wrote: > El 1 Sep 2008, a las 17:23 , Chris Withers escribió: >> Philipp von Weitershausen wrote: >>> I've personally thought for some time that it would be quite nice >>> if all you had to do was call an interface to look up a utility >>> (which is sort of a multi-adapter of order 0) or to do some kind >>> of adaption, no matter how many objects you wanted to adapt. E.g.: >> >> +sys.maxint. This is nice. >> >>> auth = IAuthentication() # utility >>> auth = IAuthentication(default=None) >>> langs = IUserPreferredLanguages(request) # adapter >>> langs = IUserPreferredLanguages(request, default=None) >>> view = IBrowserPage((obj, request), name='index')# named >>> multi-adapter >> >> Right, but how do you differentiate adapting a tuple to IBrowserPage >> versus adapting obj and request together to IBrowserPage? > > You don't, I guess. I'd say that multi-adaption is *defined* as the > adaption of a tuple. Some people who use zope.interface reply on being able to singly adapt tuples Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
On Aug 31, 2008, at 4:51 PM, Marius Gedminas wrote: > On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote: >> Wait. zope.schema really shouldn't know about terms. Terms are about >> the user interface, hence title/token. That has really *nothing* to >> do >> with zope.schema. For searching you don't need titles or tokens. >> For a >> search *UI* you do, but that doesn't belong to zope.schema either. > > Are you arguing that zope.schema.Field should not have a title > attribute? I don't think title is in the same class. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
Hi Jim > Betreff: Re: [Zope-dev] Make simple ISource usable > > > On Aug 30, 2008, at 10:54 AM, Roger Ineichen wrote: > > But zope.schema does already know about term. > > This was a mistake. Let's fix that mistake and do it right. That's all I'm asking for. Just saying no that's bad doesn't help. Any idea how we can do it? My motivation is to have less dependencies which is allways a good thing. or not? > > ... > > > ISource uses ITerm as items. > > No it doesn't. Ok, that wasn't correct. Let's say it right. ITerms uses ITerm as items. And we have widgets which know how to work with ITerms. ITerms adapter can adapt an ISource. And this adapter knows about ITerm which widgets can work with. Not every ISource have to use that pattern. But that's the second pattern we support in zope within an interface next to ISourceQueriable. Of corse everybody can implement a own API and query sources how the like to. But the benefit of a standard API like we have with ITerms is that we are able to implement reusable components which the different widget framework can use. This means ITerms should not be a part of a specific widget framework. The same is true for ISourceQueriable which is not a part of zope.app.form and that's good so. Regards Roger Ieichen > Jim > > -- > Jim Fulton > Zope Corporation > > > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
Hi Stephan > Betreff: Re: [Zope-dev] Make simple ISource usable > > On Tuesday 02 September 2008, Jim Fulton wrote: > > > This whould not affect other implementations like the > > > ISourceQueriables etc. It only offers the a way to implement > > > reusable simple ISource components without the need that every UI > > > framework needs to implement their own interfaces for > query ISource > > > component in their own way (e.g. ITerms). > > > > Why can't they use zope.app.form.interfaces.ITerms > > Because it makes every project that uses sources in a > meaningful way depend on zope.app.form, which has a lot of > dependencies that I do not want. It prohibits another form > framework, such as z3c.form to not depend on zope.app.form, > which suck to say the least. :-) > > An alternative to Roger's proposal would be to move the > ITerms declaration and any possible generic implementation of > such into its own package zope.terms. +1 I'm fine with that. Everything is better then having this interface in zope.app.form since zope.app.security is using it and glues many zope packages and the testing enviroment together. Regards Roger Ineichen > Regards, > Stephan > -- > Stephan Richter > Web Software Design, Development and Training Google me. > "Zope Stephan Richter" > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
On Tuesday 02 September 2008, Jim Fulton wrote: > > This whould not affect other implementations like > > the ISourceQueriables etc. It only offers the > > a way to implement reusable simple ISource components > > without the need that every UI framework needs to > > implement their own interfaces for query ISource > > component in their own way (e.g. ITerms). > > Why can't they use zope.app.form.interfaces.ITerms Because it makes every project that uses sources in a meaningful way depend on zope.app.form, which has a lot of dependencies that I do not want. It prohibits another form framework, such as z3c.form to not depend on zope.app.form, which suck to say the least. :-) An alternative to Roger's proposal would be to move the ITerms declaration and any possible generic implementation of such into its own package zope.terms. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
On Aug 30, 2008, at 10:54 AM, Roger Ineichen wrote: > But zope.schema does already know about term. This was a mistake. ... > ISource uses ITerm as items. No it doesn't. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Make simple ISource usable
On Aug 29, 2008, at 9:01 AM, Roger Ineichen wrote: > I'll try to make the ISource API smooth and usable > for other components. Right now ISource provides no > simple API for work with terms. > > Since a ISource only provides a __contains__ method > and the IterableSource the __iter__ method, > there is some more needed which makes it easy to > work with terms next to the ISourceQueriables API. > > The zope.app.form.browser.interfaces.ITerms > defines one possible way to make it work > like a vocabulary because it defines the methods > getTerm(value) and getValue(token). > > The z3c.form.interfaces.ITerms defines also > such a query API but right now only or vocabularies. > > I propose to define such a ITerms interface in > zope.schema.interfaces which makes it possible > to implement simple ISource terms and work with > the ITerm values like we do in vocabularies. I'm not in favor of adding UI-support interfaces to zope.schema. The presense of terms in zope.schema.interfaces was a mistake. > This whould not affect other implementations like > the ISourceQueriables etc. It only offers the > a way to implement reusable simple ISource components > without the need that every UI framework needs to > implement their own interfaces for query ISource > component in their own way (e.g. ITerms). Why can't they use zope.app.form.interfaces.ITerms > The current state of ISource/ITerms concept whould not > work if someone will switch form zope.app.form based > sources to z3c.form based sources because of it's > different ITerms implementations. Why? If the interface is the same, why does it matter if the implementations differ. > Or if someone defines a zope.schema.ISource in a 3rd party > package, the zope.app.form.browser.interfaces.ITerms is > often used for query ITerms even if it's only used in python > code without any form framework. That's a real bad dependency. Why? > Fazit, > The only query API defined for ISource in zope.schema > is the ISourceQueriables API. That's defently to less > and makes it required to implement custom query APIs > in UI frameworks if we need to work with terms. I'm not convinced that a more specific API, except maybe one based on simple search strings will be generally useful. An earlier attempt to define a query interface was a disaster. > I no one objects, I'll start a zope.schema branch and > let you know about the progress and a hopfully a simple > solution. I object. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] "zipped" versus "unzipped" eggs (was: Re: SVN: Zope2.buildout/trunk/ Don't pin setuptools.)
On Aug 30, 2008, at 2:03 AM, Dieter Maurer wrote: > Tres Seaver wrote at 2008-8-28 15:22 -0400: >> >> I don't think zipped eggs are a win in any real scenario, except >> possibly the goofy file-count-limited GAE. I would strongly prefer >> that >> you revert this one change (you can override it in your own >> '~/.buildout/default.cfg'). > > We have observed a drastic speedup (on both Windows and Linux) > in import time (about 30 %) when we have put our complete > (large) application (consisting among others of Zope 2, CMF, > Archetypes) > in a (single) zip file. ... > > However, I am not sure whether our observations for a single > large zip (in fact, we use two: one for our application, the other > for Python's > runtime library) is valid for the case of many small zipped eggs. In fact, for a small application that I wanted to be able to run as a CGI, zipping several non-large eggs (such as zope.publisher, for example) made imports slower. It was faster to use unzipped eggs. This was on Linux. Jim -- Jim Fulton Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Mon Sep 1 11:00:00 2008 UTC to Tue Sep 2 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 1 20:49:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010100.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 1 20:51:18 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010101.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 1 20:52:48 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010102.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 1 20:54:18 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010103.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon Sep 1 20:55:49 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-September/010104.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
