[Zope-dev] zope-tests - FAILED: 11, OK: 80
This is the summary for test reports received on the zope-tests list between 2011-04-16 00:00:00 UTC and 2011-04-17 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received [1]Repository policy check found errors in 270 projects Total languishing bugs for zope2: 0 [2]Total languishing bugs for zope: 53 [3]Total languishing bugs for zopeapp: 2 [4]Total languishing bugs for zopetoolkit: 198 ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.5 : Linux Zope-2.12-alltests Python-2.6.5 : Linux Zope-2.13 Python-2.6.5 : Linux Zope-2.13-alltests Python-2.6.5 : Linux Zope-trunk Python-2.6.5 : Linux Zope-trunk-alltests Python-2.6.5 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [5]winbot / z3c.coverage_py_265_32 [6]winbot / z3c.rml_py_265_32 [7]winbot / zc_buildout_dev py_254_win32 [8]winbot / zc_buildout_dev py_265_win32 [9]winbot / zc_buildout_dev py_265_win64 [10] winbot / zc_buildout_dev py_270_win32 [11] winbot / zc_buildout_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_dev py_254_win32 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED Repository policy check found errors in 270 projects https://mail.zope.org/pipermail/zope-tests/2011-April/038323.html [2]FAILED Total languishing bugs for zope: 53 https:
Re: [Zope-dev] CatalogPathAwareness and zope.lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres and all, so it looks like I came over as a total jerk who rides a personal attack on Hanno. That is of course not my intention, not at all. I am sorry for that. I am grateful for every improvement to the code and it looks like Hanno did a great job. I have expressed my regret for coming over to him like that in a personal mail to him too. What I did raise my voice for is the kind of backwards compatibility and dependability that keeps an old application in the game even with a new version of Zope, without having to go in and change everything. I want developers to keep an eye open for that, even if it's not what they need in their own work or if they believe that Zope is dead already. The case that some admin in some random company has this Zope application running somewhere and wants to move it to a new server and a new Zope version, I believe that case should not be answered with "go and write that application from scratch on some other framework". I also would like to insist that manage_afterAdd etc has been undeprecated in 2.12 both in code and in the documentation (CHANGES.txt). I will step down from my soap box in this matter now. Whatever happens, happens. Regards, Sascha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFNqzaQpYOq9ODq/IoRAnZgAKCe8YPhgKYh7do0faMIPi8+24bWMQCdEYNh GcPi/1e/cieih4xLoMRQCUg= =jQ9P -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] fanstatic and preprocessors
Hey, [snip Wolfgang] >> [1] >> http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html >> [2] https://github.com/sstephenson/sprockets Thanks for these links! We should investigate Sprockets to see what other features it has, and perhaps in the future collaborate with them on a packaging format. Regards, Martijn ___ 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] CatalogPathAwareness and zope.lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2011 10:08 AM, Sascha Welter wrote: > (Sun, Apr 17, 2011 at 07:10:07AM -0400) Tres Seaver wrote/schrieb/egrapse: >> Moving a "big old application" across multiple major versions at onece >> of any platform is likely to be painful: > > Tres, > > I know how to move an app to newer zope versions. My apps are enough > well behaved to have survived since 2.7 with few changes and from 2.10 > straight to 2.13 needed only very few adjustments so far. > > What I want to know: > > The term "CatalogPathAwareness" was not found in the archives of > zope-dev in the last 6 years or so. Can any zope developer deprecate or > remove things on their own without discussion? "Code talks." Hanno deprecated the CPA base class in r115308 in August 2010 with the comment: Fully deprecate both CatalogAwareness and CatalogPathAwareness. They are untested and unused. Event subscribers for zope.lifecycleevents are the way to go. Note that this was in the midst of a set of *huge* improveements to the catalog (the query plan stuff), for which we should be very grateful: such improvements grant legitimacy to Hanno's judgement about the state of the code. Note that if you need time to finish revising code which depends on the deprecated components, you can pin "Products.ZCatalog<=2.13.99" until your code is ready: that is one of the beauties of moving the code into a separately-released distribution. > Removing CatalogAware/CatalogPathAware from Products.ZCatalog is one > point in question. Removing manage_afterAdd et al is another. This will > break lots of code out there that would happily run on otherwise. 'manage_afterAdd' and siblings have been deprecated for a *long* time (since Zope 2.9.0b1, 2005-12-06): http://svn.zope.org/Zope/tags/2.9.0b1/doc/CHANGES.txt?rev=40603&view=markup 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2rFogACgkQ+gerLs4ltQ78KQCgoEuO3hUUt4rokZ5qndyaRx1H sZIAnjrRVwoQQmW1ncBoPO1/eN10M8rw =AvWq -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] CatalogPathAwareness and zope.lifecycle
Am 17.04.2011, 17:15 Uhr, schrieb Sascha Welter : > Charlie, > I really like this quote from the Pyramid documentation: > "While the ZCA is an excellent tool with which to build a framework such > as Pyramid, it is not always the best tool with which to build an > application due to the opacity of the zope.component APIs." > - From my point of view, wearing my "application developer hat", > event handling is YAGNI. In my estimate > - - 90% of Zope Products/Apps only use manage_afterAdd or use none of > manage_after* > - - the other 9.9% use manage_afterDelete and/or some combination for > handling copy+paste. > - - The other 0.1% thought very hard to find something else they > thought they needed to do with events. Actually, I am big fan of events - yes, you don't need them very often but they do solve provide a useful solution to some fairly common use cases. Of course, as you point out they are often best wrapped up in a higher level component. I'm not sure what your point with the numbers is about - you think event notifications and subscribers are overkill given that pretty much only manage_afterAdd and manager_afterDelete are used? Maybe, but I think that's semantics. The important thing for me is that there is no magic. As to the larger point of how suitable is the component architecture for application development I think the main point that Chris is making, and I hope he'll correct me if this is not the case, is that doing everything with the ZCA, especially with registration is counter-productive: pluggability is not really a design goal for an application. > So a full feature, "we have it all for you" framework like Zope has been > doing fine to offer these few in an easy and simple way. Pyramid gives > me full event handling as an optional extra, because Pyramid is a "you > pay only for what you eat" framework and I might not even need those few > that Zope offers out of the box - or I might be in the 0.1% and need the > full deal. I beg to differ: Zope's SimpleItem is anything but and it's bastard Plonish offspring Archetype causes even more by offering convenience at the cost of complexity. Zope as a full-featured framework is a misconception: it is an application. > Interfaces is even more YAGNI in the role of the application developer. > (Which is what the pyramid doc is saying there IMHO.) Interfaces suffer most from conceptional vagueness. As an attempt to document the intent of classes they suck - that is pretty much what docstrings are for. I have found them to be most useful as: a) marker's and b) form schema templates. Of course, b) is something probably something they really shouldn't be used. Now I tend to see them as markers first with the possibility of being expanded to full-blown interfaces if pluggability becomes desirable. > I don't write a framework where you can swap out one templating system > for another, I just write an app that is finished at one point in time. I think everyone agrees on this nowadays. I do, however, like the ability to swap out the backend for deployment purposes if required. > As for Philip's book, I guess you are aware that lots of it is already > outdated. Something to keep in mind and tell people when one recommends > that book. (Philip is well aware of that and his "in hindsight, the book > should have been free/open" blog post is quite interesting.) Some of the detail is pretty much out of date but I still think it is a great handbook on the component-based approach to application development. Speaking as someone who has no CS background and is only a part-time programmer I found it incredibly helpful in structuring my approach to problem solving and really benefited from the extensive explanation of some of the more esoteric stuff that has now become more or less standard. >> @Sascha I'm not sure if this will answer your question but you might >> want >> to look at how Products.CMFCore.CatalogAware works. > Thank you. > This would answer my question if someone told me to take over > maintenance of CatalogAware / CatalogPathAware in Products.ZCatalog > and I'd have to rewrite it instead of just writing tests and if I then > asked the question "where do I start?". I think I detect some irony there. Sorry that it doesn't help you. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CatalogPathAwareness and zope.lifecycle
Am 17.04.2011, 16:08 Uhr, schrieb Sascha Welter : > The term "CatalogPathAwareness" was not found in the archives of > zope-dev in the last 6 years or so. Can any zope developer deprecate or > remove things on their own without discussion? Technically, yes. In general there is usually a request on the mailing list because another developer could just as easily put the removed feature back. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CatalogPathAwareness and zope.lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Sun, Apr 17, 2011 at 02:58:12PM +0200) Charlie Clark wrote/schrieb/egrapse: > As for an explanation of how to use events or simply getting a grasp of > using the ZCA in Zope 2 I can highly recommend Philip von Weiterhausen's > book on Zope 3. In many ways this is the missing Zope manual. Charlie, I really like this quote from the Pyramid documentation: "While the ZCA is an excellent tool with which to build a framework such as Pyramid, it is not always the best tool with which to build an application due to the opacity of the zope.component APIs." - From my point of view, wearing my "application developer hat", event handling is YAGNI. In my estimate - - 90% of Zope Products/Apps only use manage_afterAdd or use none of manage_after* - - the other 9.9% use manage_afterDelete and/or some combination for handling copy+paste. - - The other 0.1% thought very hard to find something else they thought they needed to do with events. So a full feature, "we have it all for you" framework like Zope has been doing fine to offer these few in an easy and simple way. Pyramid gives me full event handling as an optional extra, because Pyramid is a "you pay only for what you eat" framework and I might not even need those few that Zope offers out of the box - or I might be in the 0.1% and need the full deal. Interfaces is even more YAGNI in the role of the application developer. (Which is what the pyramid doc is saying there IMHO.) I don't write a framework where you can swap out one templating system for another, I just write an app that is finished at one point in time. As for Philip's book, I guess you are aware that lots of it is already outdated. Something to keep in mind and tell people when one recommends that book. (Philip is well aware of that and his "in hindsight, the book should have been free/open" blog post is quite interesting.) > @Sascha I'm not sure if this will answer your question but you might want > to look at how Products.CMFCore.CatalogAware works. Thank you. This would answer my question if someone told me to take over maintenance of CatalogAware / CatalogPathAware in Products.ZCatalog and I'd have to rewrite it instead of just writing tests and if I then asked the question "where do I start?". Regards, Sascha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFNqwQhpYOq9ODq/IoRAs9VAKCAFxvCYu6QX2QSSfibt01rFAr2lQCfVezW NkycMDv2jMUXRLxcgC+GI7k= =xmWB -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] CatalogPathAwareness and zope.lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Sun, Apr 17, 2011 at 07:10:07AM -0400) Tres Seaver wrote/schrieb/egrapse: > Moving a "big old application" across multiple major versions at onece > of any platform is likely to be painful: Tres, I know how to move an app to newer zope versions. My apps are enough well behaved to have survived since 2.7 with few changes and from 2.10 straight to 2.13 needed only very few adjustments so far. What I want to know: The term "CatalogPathAwareness" was not found in the archives of zope-dev in the last 6 years or so. Can any zope developer deprecate or remove things on their own without discussion? Removing CatalogAware/CatalogPathAware from Products.ZCatalog is one point in question. Removing manage_afterAdd et al is another. This will break lots of code out there that would happily run on otherwise. Regards, Sascha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFNqvR6pYOq9ODq/IoRAtLlAJ0Qq7lac8cldIn89BkyQx+iXI/V2ACgqkVg u0tT7DCxBN0sCyLbwffd5Hc= =G5S7 -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] CatalogPathAwareness and zope.lifecycle
Am 17.04.2011, 13:46 Uhr, schrieb William Heymann : > I have spent some time looking at other frameworks and most just don't > look very promising to me. For grok my biggiest issue was fail open. It > looks like the default is allow everything unless explicitely denied and > I feel that is just a recipe for disaster. Pyramid looks pretty good and > it does have a > security system that you can set to fail closed but still I have a > massive investment in zope 2.x and I don't want to just throw that away > for nothing. We still manage to massively outdo our competitors using > much newer technology in time to get a solution done, in cost and in > reliability. > So I would just like to see zope 2.x remain a viable platform and if > things > are to be removed or deprecated the replacement systems need some level > of docs. Idealy, if I could, I would make it so that varous > manage_before* and manage_after* type events would just call the > zope.lifecycle stuff as a > compatibility layer so all the old code would go away but old apps would > work and the code itself would serve as instructions on how to upgrade. > That way CatalogPathAwareness would stay but basically just be a wrapper > for zope.lifecycle if that is possible. Hi, it would be great to see the things happen that you wish but the fact is Zope 2 has lost most of its developers already. If you want something in there you have to be prepared to do it yourself. I'm still a huge fan of everything that Zope achieved and agree with you totally that it is still more capable in many respects than many competitors but the world has moved on and it is important to move with it. Zope 2 is largely in maintenance mode with things being removed from the core because there is no one prepared to maintain them and they are not considered essential by those who are maintaining Zope 2 and making sure it can run on modern systems, etc. I, for one, are very grateful that this work is being done. As for an explanation of how to use events or simply getting a grasp of using the ZCA in Zope 2 I can highly recommend Philip von Weiterhausen's book on Zope 3. In many ways this is the missing Zope manual. Fortunately, many Zope inspired projects have learned from our consistent failure to provide good documentation and insist on it being part of the project. A brief and personal summary of the difference between events versus "magic" manage_* methods: events are explicit, ie. you must register a subscriber to a particular event or explicitly notify that an event has happened. This is perhaps a bit verbose but it gives you more control and helps you break functionality out of bloated classes. The signatures for event subscribers does take a while to learn but is reasonable. I suppose that it would be possible to scan source code automatically for manage_* methods and try and register subscribers on the fly but this would be against the spirit of the ZCA. In reality decorator-based registration as practised in Pyramid and Grok is a good compromise. @Sascha I'm not sure if this will answer your question but you might want to look at how Products.CMFCore.CatalogAware works. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] CatalogPathAwareness and zope.lifecycle
On Sunday 17 April 2011, Tres Seaver wrote: > Moving a "big old application" across multiple major versions at onece > of any platform is likely to be painful: even projects which are > careful about backward compatibility (Zope has historically been very > good at this) will have issued deprecation warnings in the versions you > skip. Your best bet would be to port the app stepwise to the latest > release of each major version, noting and fixing the warnings as you go. > Zope 2.12 - 2.13 is likely to be the biggest jump, because 2.13 > includes lots of changes which *remove* functionality from Zope to > optional add-ons. > I do agree with this and I have been keeping my apps current so they run on zope 2.13 and overall this has not been a huge burden. The problem is that with this change the feature used is deprecated but the replacement is not really documented anywhere so how to upgrade is not remotely clear. Zope does need to change and grow and so long as I can keep it a viable platform for what I do I will probably stay on it since it just works so amazingly well. I would just like documentation for the new systems that replace deprecated features. How is someone supposed to write a new app that uses the new event system without docs for it? If nobody is going to use the new event system what is the point of it? I have spent some time looking at other frameworks and most just don't look very promising to me. For grok my biggiest issue was fail open. It looks like the default is allow everything unless explicitely denied and I feel that is just a recipe for disaster. Pyramid looks pretty good and it does have a security system that you can set to fail closed but still I have a massive investment in zope 2.x and I don't want to just throw that away for nothing. We still manage to massively outdo our competitors using much newer technology in time to get a solution done, in cost and in reliability. So I would just like to see zope 2.x remain a viable platform and if things are to be removed or deprecated the replacement systems need some level of docs. Idealy, if I could, I would make it so that varous manage_before* and manage_after* type events would just call the zope.lifecycle stuff as a compatibility layer so all the old code would go away but old apps would work and the code itself would serve as instructions on how to upgrade. That way CatalogPathAwareness would stay but basically just be a wrapper for zope.lifecycle if that is 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] CatalogPathAwareness and zope.lifecycle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/16/2011 11:55 AM, Sascha Welter wrote: > (Fri, Apr 15, 2011 at 02:39:26PM +0200) Hanno Schlichting > wrote/schrieb/egrapse: >>> I assume this kind of thing has been discussed and the decision has been >>> taken on judging backwards compatibility vs. the benefits of doing this? >> >> The particular code was unused for several years, > > Sigh. Sorry Hanno, but just *sigh*. > > "Unused"? Unused by whom? There is code out there that uses stuff > without you or anybody else typing in the code on a keyboard. How can > you claim it's unused? Do you make audits on what pieces of code people > use in their Zope projects? > > People want to be able to move an existing Zope app to a new server and > a new Zope install there without having to sell the customer onto 15 > hours of maintenance coding to fix 100 things that break. Not every > project is a new project. > >> using manage_* >> methods is deprecated since Zope 2.8 or 2.9. > > You are wrong. > > CHANGES.txt in Zope 2.11 does not know anything about manage_* > being deprecated. Instead it says: > > - Turned deprecation warnings for manage_afterAdd, manage_beforeDelete > and manage_afterClone methods into discouraged warnings. These > methods will not be removed in Zope 2.11, but stay for the > foreseeable future. Using events is still highly encouraged. > > The CHANGES.txt from 2.12 says: > "Downgrade the ``manage_* is discouraged. You should use event > subscribers instead`` warnings to debug level logging. This particular > warning hasn’t motivated anyone to actually change any code." > And it will damn sure not motivate anybody, because code that uses that > runs just fine (thank you) and nobody sees any need to "fix" it to use > something that is undocumented and not tested in that particular setup. > That's not how maintenance on a working system works. > > CHANGES.txt in 2.13 doesn't know anything about manage_* being > deprecated or removed any further. > > If it doesn't break anything, if it doesn't break new code, why > depreciate and why remove it? We've had this same game with zLOG and > manage_afterAdd before. They're both still here, for good reason. > >> If you really need this code, just copy it from an old release into >> your own codebase. > > How about you don't delete it and I don't have to add it back? > Less work for you, less work for me, less work for everybody. > >> Developing with Zope 2 is probably a frustrating experience, but that >> shouldn't come as a surprise to anyone. > > It comes as a surprise to me. In fact, I find developing with Zope 2 > quite an amusing and entertaining experience. And easy. You must be > doing something wrong. > > I can understand though that Zope is not a system for newbies to start > *right now*, OK. > >> The project is dead for >> several years now and is only kept left alive while Plone is migrating >> away from it or some long time developers are still using it. It's a >> large piece of legacy code that has no future - certainly not for new >> users or developers not already familiar with it. > > Well, I don't know anything about what Plone is or isn't doing. No Plone > was ever able to move to a different Zope version without rewriting > basically everything, so maybe you think that's normal. It isn't like > that for most everybody else though. > > IMHO the way to treat a "large piece of legacy code" is *not* to break > various things inside it because some other idea to do things seemed so > much cooler a while back (but which we also abandoned, because we'll get > rid of it all anyway). > > The way to do that properly is to make it as stable an lasting as you > can and let it stay alive till it falls over by itself. So if you think > it's dead, OK, but there is no reason to actively kill it piece by piece. Moving a "big old application" across multiple major versions at onece of any platform is likely to be painful: even projects which are careful about backward compatibility (Zope has historically been very good at this) will have issued deprecation warnings in the versions you skip. Your best bet would be to port the app stepwise to the latest release of each major version, noting and fixing the warnings as you go. Zope 2.12 - 2.13 is likely to be the biggest jump, because 2.13 includes lots of changes which *remove* functionality from Zope to optional add-ons. 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2qyo8ACgkQ+gerLs4ltQ4LxgCeMDpTlyI21tcIOSnyIthn55Qs cWIAn1AAOfjk4+OOjrX1phVRk2dxF51f =67vM -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zo
