Re: [Zope-dev] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
Hanno Schlichting wrote: > From my point of view most of the original UI building blocks of Zope > 3 have failed to catch on. More modern systems like repoze.bfg prefer > a much simpler model using ZPT macros or trying to mirror the CMF > skins model. In the Plone world we adopted the CA to build and > customize our UI and it has been a massive failure. I think the > fundamental problem of these technologies is, that they have been > built by developers for developers. We made it incredible hard for > non-developers to do anything meaningful with our UI. I'm not sure I'd agree completely with what you're saying. I think *viewlets* have been a problem in the way that they are used in Plone, i.e. as a general page composition mechanism. In hindsight, I wish we'd had maybe half a dozen viewlet providers at most, used only for things like status messages or extra content being plugged in by third party systems. On balance, I think browser views have provided a huge benefit over what people were doing before, in that they provide a sane place to put "display logic". I know the separate ZCML registration step has been a hampering for some, but with grokcore.view/five.grok that's become easier. Customisation is still not as esay as it is with portal_skins, unless you're using z3c.jbot, in which case it's arguably easier. I don't necessarily disagree with your diagnosis: too many of these things were written by developers for developers. It seems sometimes like the goal of a "pluggable" UI, where packages plug themselves into an overall structure, has been allowed to overshadow the goal of a "customiseable" UI, where integrators can easily customise the UI to their needs. However, on balance, I think the move to Zope 3-style views, at least, has been positive. I'm in the intersting position right now of teaching "new" techniques to a team that has been on Plone 2.5 and done everything TTW for a long time. Some "new" things they reject as too obscure. But there are more "new" techniques that they see as a blessing, recognising many of the problems they had in the past. Careful with the bathwater again... :-) 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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi! > > > Hanno Schlichting wrote: >> On Sun, Dec 27, 2009 at 5:43 PM, yuppie wrote: >>> Why not following the normal procedure? At some point in the past we >>> decided to add formlib support to Zope 2. That's a commitment. We should >>> not drop features just like that. >> I think five.formlib is better served by being a separate distribution >> that can evolve on its own, much like we do it with >> five.localsitemanager. I don't understand this as dropping the >> support, but as shifting the maintenance to a different group. Both >> CMF and Plone use formlib today and have both come up with additions >> and new features for it. I want those to go into five.formlib. Having >> the code in Zope2 seems to prevented people from doing so. >> >> On the other side many people in the Plone community have started >> using z3c.form instead of formlib and it looks like all of Plone will >> shift to that. > > Exactly. And I expect CMF will also switch to z3c.form. > >> Once that happens I don't want to have formlib to still >> be there as a dependency of Zope2 for all eternity. > > Agreed. I did just argue against the fast removal Tres proposed. > > But five.formlib will only evolve for a short period. Soon it will > become a pure legacy package. Nothing we want to recommend for new > projects. And in the long run five.formlib and its non-ZTK dependencies > will become unmaintained. That is why I want to get it out of the tree *before* 2.13: anybody who needs to use Zope2 but can't add an extra five.formlib egg should just stay on 2.12 until they can. Deprecations are not a cure for this: folks will just defer the pain until the release cycle where things actually disappear, and meanwhile the "core" maintenance is harder. Splitting less-maintained code out into a searate distribution allows for the "conservative" crew to keep using it, while not taxing the mainstream (and the core developers) to support them. Given that 2.13 is unlikely to be out before Q3 of 2010, how hard is it going to be for folks to catch up, anyway? Plone 4 will ship on top of 2.12, Plone 5 is already a more radical break, and can easily accomodate the split (or abandon formlib, whichever). 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 iEYEARECAAYFAks361cACgkQ+gerLs4ltQ5nbwCfZbcenLP8RmBbhUj9X20oMnxe mA0An0mbrN4FNaCrwIK2WzHFXSpg+/T+ =l0dx -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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
Hi! Hanno Schlichting wrote: > On Sun, Dec 27, 2009 at 5:43 PM, yuppie wrote: >> Why not following the normal procedure? At some point in the past we >> decided to add formlib support to Zope 2. That's a commitment. We should >> not drop features just like that. > > I think five.formlib is better served by being a separate distribution > that can evolve on its own, much like we do it with > five.localsitemanager. I don't understand this as dropping the > support, but as shifting the maintenance to a different group. Both > CMF and Plone use formlib today and have both come up with additions > and new features for it. I want those to go into five.formlib. Having > the code in Zope2 seems to prevented people from doing so. > > On the other side many people in the Plone community have started > using z3c.form instead of formlib and it looks like all of Plone will > shift to that. Exactly. And I expect CMF will also switch to z3c.form. > Once that happens I don't want to have formlib to still > be there as a dependency of Zope2 for all eternity. Agreed. I did just argue against the fast removal Tres proposed. But five.formlib will only evolve for a short period. Soon it will become a pure legacy package. Nothing we want to recommend for new projects. And in the long run five.formlib and its non-ZTK dependencies will become unmaintained. Cheers, Yuppie ___ 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] Zope Toolkit - packages with zope.app dependencies
On Sun, Dec 27, 2009 at 5:04 PM, Baiju M wrote: > So, ZTK is ready for 1.0 final release ? Far from it. After we managed the huge chunk of technical work, we still need to start working on all the not-so-fun process stuff around it. Typical questions are: - How do we find a release manager? - Without a single person being responsible nothing ever gets done. - Who is appointing that person and what duties and power does he have? Is the Steering group enough or is the Zope Foundation the right organization to appoint that person? - How do the roadmaps of the toolkit users look like and when would it make sense for them to have a release? - A ZTK release that isn't actually used by any of Grok, repoze.bfg, Zope2 or whatever comes out of Zope 3 seems rather pointless to me. Anyone can use the SVN version of the ZTK definition at any point, which is the same as rolling your own kgs/index. The large projects have to be able to rely on a certain stability and regularity of releases for years. Or they don't actually use the ZTK KGS but are all rolling their own version of it. - What kind of release cycle should the ZTK have, which is closely related to the above. The ZTK release cycle needs to be somehow aligned to those of its users. Or otherwise most of its value of actually sharing the maintenance burden of the whole thing is gone. - Is there anyone interested in continuing the work on Zope 3 or provide a migration strategy for it? Both Zope2 and Grok have found their own ways to deal with this, so none of the two have an interest in working on such an upgrade story. But it's clear that there are users of Zope 3 out there, that should get some official story, whatever that might be. - How does the process for feature enhancements and proposals for the ZTK look like? Christian started some of the docs but it's all far from finished and we don't actually use any of this process. Currently there's an urge to drop support for Python 2.4, work on Python 3.1 support has started, the CA has seen various proposals for potentially backwards compatible changes, ... there needs to be some process where the toolkit users can raise their concerns, so that they can use ZTK releases and the changes from one release to the next match their progress and deprecation policies. I'm sure there's many more of these questions, where most of them don't have a clear or even objective answer :-) I suggest we wait until the x-mas holidays are over, so everyone has a chance to take part in these discussions. The steering group members have been rather silent and might all be taking vacation ;) 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 )
Re: [Zope-dev] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
On Sun, Dec 27, 2009 at 5:43 PM, yuppie wrote: > Tres Seaver wrote: >> Hanno Schlichting wrote: > +1 for shipping Zope 2.12.3 with five.formlib > > -1 for adding new deprecation warnings in a bugfix release Ok. So I'll backport five.formlib to the 2.12 branch leaving BBB imports, have 2.13 issue deprecation warnings pointing to removal in 2.14. Unless Andreas prefers a different approach :) > Why not following the normal procedure? At some point in the past we > decided to add formlib support to Zope 2. That's a commitment. We should > not drop features just like that. I think five.formlib is better served by being a separate distribution that can evolve on its own, much like we do it with five.localsitemanager. I don't understand this as dropping the support, but as shifting the maintenance to a different group. Both CMF and Plone use formlib today and have both come up with additions and new features for it. I want those to go into five.formlib. Having the code in Zope2 seems to prevented people from doing so. On the other side many people in the Plone community have started using z3c.form instead of formlib and it looks like all of Plone will shift to that. Once that happens I don't want to have formlib to still be there as a dependency of Zope2 for all eternity. On the more general note of Five: When it comes to most of the Five code, there has only been a decision to include and transition to the Zope 3 app server as a whole at some point. We know this story hasn't played out. Now I'd like to look at each zope.* package in its own right and see if it and its five integration code is warranted to be part of Zope2. Certainly interfaces, the general CA, zope.configuration, zope.event, zope.tal, zope.i18n, parts of publishing and traversal have all been integrated into Zope2 and are used inside the Zope2 code. The same applies to browser views and pages. But when it comes to formlib, testbrowser, viewlets/contentproviders, resources, menus and the default skin via @@standard_macros the situation is all much less clear. >From my point of view most of the original UI building blocks of Zope 3 have failed to catch on. More modern systems like repoze.bfg prefer a much simpler model using ZPT macros or trying to mirror the CMF skins model. In the Plone world we adopted the CA to build and customize our UI and it has been a massive failure. I think the fundamental problem of these technologies is, that they have been built by developers for developers. We made it incredible hard for non-developers to do anything meaningful with our UI. So I think it's time to look at the stuff in Five and ask ourselves what of it are actually good libraries and concepts. And want of that stuff we want to keep promoting. And even if want to keep it, I think we should split up Zope2 into multiple distributions - we just need to be more careful with it, than the Zope 3 egg explosion. 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 )
Re: [Zope-dev] Zope 2: circular import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: > Hi! > > > I stumbled over a circular import in Zope 2. > > > in DocumentTemplate.DT_Util: > from ZPublisher.TaintedString import TaintedString > > this triggers ZPublisher.BaseRequest with: > from AccessControl.ZopeSecurityPolicy import getRoles > > this triggers AccessControl.DTML with: > from DocumentTemplate import DT_Util > > > With try/except imports and the right import order this works, but it > would be better to break up that circle. > > At first glance the solution is simple: TaintedString doesn't have any > dependencies and is used by DocumentTemplate and ZPublisher. So it > should be moved to a place where both modules can use it without > triggering countless imports. > > But where would be a good place for TaintedString? It is too small to > create a package just for that. In which existing package would it fit? > > Or should we just add a copy of TaintedString to DocumentTemplate? Put it in Shared.DC.Scripting? ZPT and DTML already depend on it, I think (oops, no, ZPT and PythonScript, but not DTML). Or just put it in a module / package in the Zope2 distribution's 'src' directory. While we're at it, the circular import between ZServer and ZPublisher is insane, too. 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 iEYEARECAAYFAks3ogsACgkQ+gerLs4ltQ7n2ACfS2eKzoshRz2KuyJIsi+9WIHO ZLcAoIfIINZDKtedf3LWfyGYoFT9iPHS =0owd -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] Zope 2: circular import
Hi! I stumbled over a circular import in Zope 2. in DocumentTemplate.DT_Util: from ZPublisher.TaintedString import TaintedString this triggers ZPublisher.BaseRequest with: from AccessControl.ZopeSecurityPolicy import getRoles this triggers AccessControl.DTML with: from DocumentTemplate import DT_Util With try/except imports and the right import order this works, but it would be better to break up that circle. At first glance the solution is simple: TaintedString doesn't have any dependencies and is used by DocumentTemplate and ZPublisher. So it should be moved to a place where both modules can use it without triggering countless imports. But where would be a good place for TaintedString? It is too small to create a package just for that. In which existing package would it fit? Or should we just add a copy of TaintedString to DocumentTemplate? Any ideas? Cheers, Yuppie ___ 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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
Hi! Tres Seaver wrote: > Hanno Schlichting wrote: >> But in order to get Zope2 really app-free we need to drop the direct >> five.formlib dependency at some point, or we still pull things in via >> transitive dependencies. >> >> Is deprecating in 2.13 and removal in 2.14 ok? +1 Since it doesn't make sense to mark five.formlib and zope.app.* as deprecated, it would be helpful to announce that ZTK and Zope 2 maintainers will no longer support these packages after Zope 2.12.3. >> Or does anyone have a >> different preference? Is it ok to backport this to 2.12? +1 for shipping Zope 2.12.3 with five.formlib -1 for adding new deprecation warnings in a bugfix release > +1 to dropping it in Zope 2.13: folks who are using it will > just need to add one egg to their buildouts (or their install_requires) > and adjust imports, right? Anyway, in the interests of getting to a > clean "runs on ZTK" label sticker on the box, "onward and upward." Why not following the normal procedure? At some point in the past we decided to add formlib support to Zope 2. That's a commitment. We should not drop features just like that. Zope 2.13 can still have the "runs on ZTK" label if it ships with additional packages. Cheers, Yuppie ___ 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] Zope Toolkit - packages with zope.app dependencies
Congrats to all those involved in this work! So, ZTK is ready for 1.0 final release ? ___ 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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
On Sun, Dec 27, 2009 at 3:10 PM, Tres Seaver wrote: > Hanno Schlichting wrote: >> Is deprecating in 2.13 and removal in 2.14 ok? Or does anyone have a >> different preference? Is it ok to backport this to 2.12? > > +1 to dropping it in Zope 2.13: folks who are using it will > just need to add one egg to their buildouts (or their install_requires) > and adjust imports, right? Anyway, in the interests of getting to a > clean "runs on ZTK" label sticker on the box, "onward and upward." Ok. I'm in favor of that. I'd only do it if we backport this stuff to 2.12, so you get at least one release with deprecation warnings. I'd be willing to adjust CMF to use all the new imports ;) I think it also might be a good idea to move some of the formlib helper classes from CMF into the five.formlib package. There's some helper classes for property conversion and such, which should be more low-level. Andreas, any objections to this backport? 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 )
Re: [Zope-dev] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > On Sun, Dec 27, 2009 at 6:55 AM, Tres Seaver wrote: >> Hanno Schlichting wrote: >>> Log message for revision 107134: >>> Moved zope.formlib / zope.app.form integration into a separate package >>> called five.formlib. >> YAY! You rock, Hanno. > > Thanks, we all did our part to get Zope2 "zope.app"-free :) > > One question about the separation remains, though. When and how can we > drop the five.formlib dependency from Zope2 itself? The deprecation > warnings don't mention a release or date when they'll be gone. > > But in order to get Zope2 really app-free we need to drop the direct > five.formlib dependency at some point, or we still pull things in via > transitive dependencies. > > Is deprecating in 2.13 and removal in 2.14 ok? Or does anyone have a > different preference? Is it ok to backport this to 2.12? +1 to dropping it in Zope 2.13: folks who are using it will just need to add one egg to their buildouts (or their install_requires) and adjust imports, right? Anyway, in the interests of getting to a clean "runs on ZTK" label sticker on the box, "onward and upward." 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 iEYEARECAAYFAks3atEACgkQ+gerLs4ltQ6uyACg16sfVuN3MMwnQoafBjqzUJE/ 41YAnAoCD8TBLi8LFd7MQCZ7B8IO+H0q =GN1X -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] Zope Toolkit - packages with zope.app dependencies
Hi. On Sun, Dec 27, 2009 at 2:23 PM, Roger wrote: > Just assinged Owner roles for "fafhrd" and "hannosch" > to zope.initid, zope.catalog and zope.app.testing Thanks! I made new releases of both of them and put them back into the ZTK. 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Hi Hanno, Nikolay Just assinged Owner roles for "fafhrd" and "hannosch" to zope.initid, zope.catalog and zope.app.testing Regards Roger Ineichen > -Ursprüngliche Nachricht- > Von: zope-dev-boun...@zope.org > [mailto:zope-dev-boun...@zope.org] Im Auftrag von Hanno Schlichting > Gesendet: Sonntag, 27. Dezember 2009 13:46 > An: Nikolay Kim > Cc: zope-dev > Betreff: Re: [Zope-dev] Zope Toolkit - packages with zope.app > dependencies > > On Sun, Dec 27, 2009 at 7:16 AM, Nikolay Kim > wrote: > >> zope.catalog and zope.intid > > > > i've just removed zope.app.testing dependency from > zope.intid package > > i need access to pypi package to make release, my id 'fafhrd' > > Awesome, that's exactly the constructive response I love to see :) > > Unfortunately I don't have PyPi access to these packages > myself. Can someone give "fafhrd" and "hannosch" access > rights, please? > > 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 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] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
On Sun, Dec 27, 2009 at 6:55 AM, Tres Seaver wrote: > Hanno Schlichting wrote: >> Log message for revision 107134: >> Moved zope.formlib / zope.app.form integration into a separate package >> called five.formlib. > > YAY! You rock, Hanno. Thanks, we all did our part to get Zope2 "zope.app"-free :) One question about the separation remains, though. When and how can we drop the five.formlib dependency from Zope2 itself? The deprecation warnings don't mention a release or date when they'll be gone. But in order to get Zope2 really app-free we need to drop the direct five.formlib dependency at some point, or we still pull things in via transitive dependencies. Is deprecating in 2.13 and removal in 2.14 ok? Or does anyone have a different preference? Is it ok to backport this to 2.12? 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
On Sun, Dec 27, 2009 at 9:54 AM, Martin Aspeli wrote: > It sounds like it'd be possible to fix these test dependencies in a > different way. I agree that the ideal solution is to have a zope.intid > with more sane test dependencies. I'm not sure pre-emptive ejection > from the ZTK is the way to get there, though. It seems it worked out exactly as I had hoped for, thanks to Nikolay Kim. Once one of us gets PyPi permissions for zope.intid, it's back in :) Sorry, I'm not good at encouraging people to do something, I only know how to use a little stick ;) 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
On Sun, Dec 27, 2009 at 8:12 AM, Shane Hathaway wrote: > Hanno Schlichting wrote: >> It has a dependency on zope.app.publication. Given the central role of >> zope.traversing I allowed it and zope.app.publication to stay in the >> ZTK, but moved it to the under-review option. > > On the zope.traversing trunk, I have removed the zope.app.publication > dependency. It was only a testing dependency. Great. It looked to me like there was an actual semantic dependency between the two packages. > What other ZTK packages depend on zope.app.publication? zope.app.publication > is an extra layer of complexity that most sites could probably do without. There's none. I released a new zope.traversing and updated the ZTK. It's now really app-free :) 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 )
Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
On Sun, Dec 27, 2009 at 7:16 AM, Nikolay Kim wrote: >> zope.catalog and zope.intid > > i've just removed zope.app.testing dependency from zope.intid package > i need access to pypi package to make release, my id 'fafhrd' Awesome, that's exactly the constructive response I love to see :) Unfortunately I don't have PyPi access to these packages myself. Can someone give "fafhrd" and "hannosch" access rights, please? 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] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Sat Dec 26 12:00:00 2009 UTC to Sun Dec 27 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Dec 26 20:37:05 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013269.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Dec 26 20:39:06 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013270.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 26 20:41:06 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013271.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 26 20:43:06 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013272.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 26 20:45:06 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013273.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Dec 26 20:47:06 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013274.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] Avoid deprecation warnings in the testrunner
On Sun, Dec 27, 2009 at 10:44, Fabio Tranchitella wrote: > * 2009-12-25 10:23, Lennart Regebro wrote: >> Yes, we did. But now we try to get the deprecation warnings to show up in >> the correct place. And we could warn for the usage of some of the names, >> but in the message explain that doctest.py is deprecated. > > What do you think about the attached patch (applied to the current trunk)? > It makes the tests quite noisy (each usage of DocTestSuite and DocFileSuite > raises a warning), but I think matches with what you wrote in the quoted > paragraph above. Yeah, I think that make sense. Seems a simple solution that works. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ 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] Avoid deprecation warnings in the testrunner
* 2009-12-25 10:23, Lennart Regebro wrote:
> Yes, we did. But now we try to get the deprecation warnings to show up in
> the correct place. And we could warn for the usage of some of the names,
> but in the message explain that doctest.py is deprecated.
What do you think about the attached patch (applied to the current trunk)?
It makes the tests quite noisy (each usage of DocTestSuite and DocFileSuite
raises a warning), but I think matches with what you wrote in the quoted
paragraph above.
Thanks,
Fabio
Index: src/zope/testing/doctest/__init__.py
===
--- src/zope/testing/doctest/__init__.py (revisione 107149)
+++ src/zope/testing/doctest/__init__.py (copia locale)
@@ -108,11 +108,6 @@
warnings.filterwarnings("ignore", "is_private", DeprecationWarning,
__name__, 0)
-# Tell people to use the builtin module instead.
-warnings.warn('zope.testing.doctest is deprecated in favour of '
- 'the Python standard library doctest module', DeprecationWarning,
- stacklevel=2)
-
class UnusedFootnoteWarning(Warning):
"""Warn about a footnote that is defined, but never referenced."""
@@ -2381,6 +2376,9 @@
A set of doctest option flags expressed as an integer.
"""
+warnings.warn('zope.testing.doctest is deprecated in favour of the Python '
+'standard library doctest module', DeprecationWarning, stacklevel=2)
+
if test_finder is None:
test_finder = DocTestFinder()
@@ -2512,6 +2510,9 @@
encoding
An encoding that will be used to convert the files to unicode.
"""
+warnings.warn('zope.testing.doctest is deprecated in favour of the Python '
+'standard library doctest module', DeprecationWarning, stacklevel=2)
+
suite = unittest.TestSuite()
# We do this here so that _normalize_module is called at the right
___
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 )
