Re: [Zope-dev] setup.py "extra" dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: > (http://pypi.python.org/pypi/eggtestinfo) > > I skimmed the docs, but they were written generically, so I couldn't > confirm: Tres, is this the thing that lets you run ``setup.py test`` > against zope.testing, if you configure it properly? The last example > seemed like that was it. At the moment, our testing story can't use things like 'tests_require', etc., because they are only known at the time 'setup()' runs. eggtestinfo addresses this problem by writing introspectable metadata into the "egg info" directory: this information derives from the various testing-related arguments passed to 'setup()'. I worked some on getting ZODB / transaction etc. to run at least most of their tests from 'setup.py test' (those which don't require layer setup). The last example shows the metadata from a package which uses the new 'test_loader' I wrote for this purpose. I also added another setuptools plugin to 'zope.testing', to allow running all tests via 'setup.py ftests'. > If so, +1 on getting this into zope.testing, or at least this pattern > into our standard ways of writing tests. IME, that's what non-Zope > Python developers expect (as Tres has argued before). It's a small > thing, but would get the non-Zope Python developer's experience off on > the right foot. > > Tres, you've obviously done the research here to know: can we easily > change zope.testing to make that story work? Or would you say that > eggtestinfo is still a better/easier way to go about it, at least for > now? Somebody likely needs to extend zc.buildout (or a recipe?) to use the information generated by 'eggtestinfo' when building testrunner scripts. My zc.buildout-fu is pretty weak at this point :(. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsa3N+gerLs4ltQ4RAqHAAKCHtx51GXslMXXBJKVOEC9SkkLTzACgl/IC bPKpvcGR8fwzsZC9mqwjwvA= =8wSw -END 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] setup.py "extra" dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: > 2009/3/6 Tres Seaver : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Martijn Faassen wrote: >>> Hey, >>> >>> Laurence Rowe wrote: >>> [snip] It seems there is a 'tests_require' >>> One reason that isn't used is that apparently there is no way for us to >>> dig up this information in the way our test runner needs, unlike extras >>> requires. >> If the testrunner would require 'eggtestinfo', and introspect the extra >> data it records, this wouldn't be true any longer. > > +1. Though, if that "eggtestinfo" package is really tiny, as I believe > it is, we could just copy it into the testrunner not to create extra > dependencies. Its job is to register a setuptools plugin which writes extra 'egginfo': it therefore has to be used as a 'setup_requires' dependency (otherwise you have to deal with obscure "first time" failures). I think it would make more sense to leave it around as a tiny dependency which we use everywhere. Making the testrunner smart enough to use the information written by the plugin is probably more than my brain can cope with at 6:00 on a Friday evening. :) 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsawP+gerLs4ltQ4RAo7CAJ9GZL4vS0BT7D9TtpQmoZ3H+8zvJgCgk6Wo pSFmfNPy87+mexXoSEuvdEM= =sLMs -END 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] zope.publisher uses deprecated IView
On Friday 06 March 2009, Martijn Faassen wrote: > I'd definitely be in favor of trying this instead of undeprecating them. > zope.component has no business knowing about views and such. +1 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] setup.py "extra" dependencies
On Mar 6, 2009, at 4:30 PM, Dan Korostelev wrote: > 2009/3/6 Tres Seaver : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Martijn Faassen wrote: >>> Hey, >>> >>> Laurence Rowe wrote: >>> [snip] It seems there is a 'tests_require' >>> >>> One reason that isn't used is that apparently there is no way for >>> us to >>> dig up this information in the way our test runner needs, unlike >>> extras >>> requires. >> >> If the testrunner would require 'eggtestinfo', and introspect the >> extra >> data it records, this wouldn't be true any longer. > > +1. Though, if that "eggtestinfo" package is really tiny, as I believe > it is, we could just copy it into the testrunner not to create extra > dependencies. (http://pypi.python.org/pypi/eggtestinfo) I skimmed the docs, but they were written generically, so I couldn't confirm: Tres, is this the thing that lets you run ``setup.py test`` against zope.testing, if you configure it properly? The last example seemed like that was it. If so, +1 on getting this into zope.testing, or at least this pattern into our standard ways of writing tests. IME, that's what non-Zope Python developers expect (as Tres has argued before). It's a small thing, but would get the non-Zope Python developer's experience off on the right foot. Tres, you've obviously done the research here to know: can we easily change zope.testing to make that story work? Or would you say that eggtestinfo is still a better/easier way to go about it, at least for now? Gary ___ 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.publisher uses deprecated IView
Dan Korostelev wrote: > 2009/3/6 Tres Seaver : [snip] >> I just undeprecated IView and the other 'bbb' interfaces for exactly >> this reason: if core packages still use them five years later, then the >> deprecation loses. > > I doubt that the IView and (especially) > IPresentation/IContextDependent are actually imported/used anywhere > directly. Especially when they were deprecated for years. So I'm +10 > on simply removing the inheritance and that BBB interfaces themselves, > as they only create confusion when someone tries to find out what > those interfaces constist of. I'd definitely be in favor of trying this instead of undeprecating them. zope.component has no business knowing about views and such. Regards, Martijn ___ 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] setup.py "extra" dependencies
2009/3/6 Tres Seaver : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martijn Faassen wrote: >> Hey, >> >> Laurence Rowe wrote: >> [snip] >>> It seems there is a 'tests_require' >> >> One reason that isn't used is that apparently there is no way for us to >> dig up this information in the way our test runner needs, unlike extras >> requires. > > If the testrunner would require 'eggtestinfo', and introspect the extra > data it records, this wouldn't be true any longer. +1. Though, if that "eggtestinfo" package is really tiny, as I believe it is, we could just copy it into the testrunner not to create extra dependencies. -- WBR, Dan Korostelev ___ 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] producing a list of packages in the Zope Framework?
Stephan Richter wrote: > On Wednesday 04 March 2009, Martijn Faassen wrote: >> But I'm sure we can find more packages to evict from the Zope Framework. > > Martijn, I was just planning to split up the KGS in the next week and see > what > happens. But if I have a list to start out with I'll take it. :-) Cool! Hanno posted a list, so that sounds like a starter list to me. Regards, Martijn ___ 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.publisher uses deprecated IView
2009/3/6 Tres Seaver : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martijn Faassen wrote: >> Hey, >> >> Wolfgang Schnerring wrote: >>> since Dan Korostelev commented on my >>> https://bugs.launchpad.net/zope3/+bug/338136 >>> saying I should take it to the mailing list, here goes: >>> >>> zope.publisher.interfaces.browser.IBrowserView inherits from >>> zope.component.interfaces.IView, which actually is >>> zope.component.bbb.interfaces.IView -- marked as deprecated since >>> 2004, but no pointer what the replacement should be. >>> >>> What's going on here? >> >> I actually remember running into this many many years ago and got so >> confused I gave up on it then. :) Hopefully someone else can tell you more! >> >> Something is definitely funky in here. >> >> I wonder what happens to our compattests if we simply remove this >> inheritance relationship. If nothing directly refers to IView it might >> mean everything will still work... > > I just undeprecated IView and the other 'bbb' interfaces for exactly > this reason: if core packages still use them five years later, then the > deprecation loses. I doubt that the IView and (especially) IPresentation/IContextDependent are actually imported/used anywhere directly. Especially when they were deprecated for years. So I'm +10 on simply removing the inheritance and that BBB interfaces themselves, as they only create confusion when someone tries to find out what those interfaces constist of. As for others, I bet IResource could be safely moved into zope.app.publisher and the IDefaultViewName - to zope.publisher to make company for IDefaultSkin. :) As for IViewFactory/IResourceFactory - they are not used by zope. For example, the BrowserView and BrowserPage classes don't provide those interfaces. So I propose to simply remove them. -- WBR, Dan Korostelev ___ 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] producing a list of packages in the Zope Framework?
On Wednesday 04 March 2009, Martijn Faassen wrote: > But I'm sure we can find more packages to evict from the Zope Framework. Martijn, I was just planning to split up the KGS in the next week and see what happens. But if I have a list to start out with I'll take it. :-) 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.publisher dependencies
Martijn Faassen wrote: > Jim Fulton wrote: > [snip] >> I'd rather leave zope.publsiher more or less alone, but develop a new >> thing that has the basic/core functionality we need and refactor >> zope.publisher to use that. > > I had the impression Shane was doing that; i.e. building zope.pipeline > factoring bits out of the publisher but not really changing the > publisher very much itself, creating a new structure instead. Shane, is > that correct? Yes. I think Jim and I are saying the same thing there. The current code in zope.pipeline doesn't reflect that thinking, though, because we really need to divide zope.publisher somehow before a project like this makes sense. > +1 on the WebOb compatibility. I imagine it should be possible to > reconstruct our request and response interfaces on top of WebOb's. We > should also think of ways so that code can get the WebOb request > directly instead of having to go through these adapters. I'd also be > much in favor of reusing WebOb's implementation, not just the APIs. I > think it could help us replace part of the publisher. That should be a great thing to work on in a sprint. > Thanks. I'm very much in favor of you guys talking at PyCon if that's > the best way to make progress. I'm also looking forward to seeing Shane > again at PyCon after meeting him so briefly all these years ago when I > was still young and nimble. So I'm glad to hear he's going to make it! > I'm also happy I'll get to see you again as well! I'll be the one who arrives Monday afternoon without much hair on top. :-) Shane ___ 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] Stripping down zope.component
Tres Seaver wrote: [snip] I'd say leave the extra shim in place for the time being. We can then see about getting rid of that at some point. > In any package where I create a backward incompatibility, I will > certainly document it clearly, with instructions on how to update > dependent packages. Putting the canonical docs in the package is an > absolute necessity for reuse of the package outside any larger package > set, anyway. Agreed about that. Concerning a master list of changes. Let's ignore the concept of lockstep releases for the time being in this discussion. We can easily decouple this from the discussion about a list of major changes to various zope packages. I'd still like there to be a master list marks big changes that people need to be aware of when they upgrade their packages to newer versions. If they're going to make their own package lists, they can get an overview of what to watch out for. And us people who maintain lists of such packages that get release numbers can also look out for those. This isn't a list by version but just a list maintained by date, or per change. Now that I think about it, we can turn it around and aggregate the existing CHANGES.txt as news somehow. Perhaps some way to turn them into Atom feeds; a script would then be simple enough to write to aggregate all non-bugfix releases. Regards, Martijn ___ 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.publisher uses deprecated IView
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > Wolfgang Schnerring wrote: >> since Dan Korostelev commented on my >> https://bugs.launchpad.net/zope3/+bug/338136 >> saying I should take it to the mailing list, here goes: >> >> zope.publisher.interfaces.browser.IBrowserView inherits from >> zope.component.interfaces.IView, which actually is >> zope.component.bbb.interfaces.IView -- marked as deprecated since >> 2004, but no pointer what the replacement should be. >> >> What's going on here? > > I actually remember running into this many many years ago and got so > confused I gave up on it then. :) Hopefully someone else can tell you more! > > Something is definitely funky in here. > > I wonder what happens to our compattests if we simply remove this > inheritance relationship. If nothing directly refers to IView it might > mean everything will still work... I just undeprecated IView and the other 'bbb' interfaces for exactly this reason: if core packages still use them five years later, then the deprecation loses. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUkc+gerLs4ltQ4RAuNxAJwK+mWmEesGrBEBDRGAbVRmmjJ2kACeONam pIs6yQadsfbwT/n5XFcwC+4= =C8ps -END 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] setup.py "extra" dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hey, > > Laurence Rowe wrote: > [snip] >> It seems there is a 'tests_require' > > One reason that isn't used is that apparently there is no way for us to > dig up this information in the way our test runner needs, unlike extras > requires. If the testrunner would require 'eggtestinfo', and introspect the extra data it records, this wouldn't be true any longer. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUiO+gerLs4ltQ4RAkrdAJ9BPlqpeVScIMPXAKvc2RjTP1fAiACaAosw 3hd36GBYlzeQFahZzqVA6dM= =UodN -END 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] Stripping down zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > Tres Seaver wrote: > [snip] >> Actually, we don't need an upgrade path. We can just leave a >> 'meta.zcml' in zope.component which the new locations. That >> file will be *inert*, and doesn't therefore need testing, because none >> of the directive implementations will be present. >> >> Over time, people can shift to including the new meta.zcml at their >> leisure. We can leave the redirecting meta.zcml in zope.component >> *forever*, if need be. > > It's not just the meta.zcml story, where I can agree we could leave > something in place, but it's the dependencies in setup.py, right? Right. Dropping any dependency on zope.configuration, zope.security etc. *will* happen. The folks affected by such a change will be those who rely on the current transitive dependency graph to pull in those pacakges: they will need to update their versions.cfg / setup.py, etc. in order to pick up the new version of zope.component. See below for the documentation required. > If the implementation of the directives lives in zope.componentzcml, any > codebase that loads any ZCML at all (in its tests especially) is very > likely to need zope.componentzcml besides zope.component. Or am I > missing something here? It needs to have it importable, yes (so that the redirected meta.zcml works). Come to think of it, we could even leave the extras in place for BBB, since anybody who has been relying on the transitive graph has to be depending on 'zope.component[zcml]' already, right? I don't have a problem with leaving it in place as a pure dependecy shim. > [snip] >>> Anyway, this upgrade path needs to be spelled out clearly in the >>> zope.component CHANGES.txt pointing people in the right direction. We >>> also need to spell it out in this document: >>> >>> http://svn.zope.org/zope3docs/source/migration/34to35.rst >> Maintaining that document is out of scope for me. ;) > > If my above story about the dependencies is right, it is necessary to > remark this in a central place. We do have framework-wide policies in > place, and explaining to people how to unbreak their code in a single > place they can look should be one of them. We do after all have people > who use a whole bunch of these libraries at the same time. But if you > can write it clearly in the CHANGES.txt and tell me, I'll add it to that > document if you can't be bothered. It isn't that I can't be bothered: I'm don't want to reinforce the idea of a new monolithic release labeled "3.5" to which people will upgrade from the current "3.4" in lockstep. Not only do I not want to *use* such a monolith; I'm convinced that trying to maintain it can impede (and has impeded) develpoment of the actual bits which make it up. I won't do anything active to defeat your efforts in that direction, but I don't want to help on that part. In any package where I create a backward incompatibility, I will certainly document it clearly, with instructions on how to update dependent packages. Putting the canonical docs in the package is an absolute necessity for reuse of the package outside any larger package set, anyway. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUeQ+gerLs4ltQ4RAihbAJ4gwRemxOz7/CT/wQUpkLEd++EQFgCfUHm6 0i2xCkbvckMB/pp59ezpCKk= =n7Fv -END 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] zope.publisher dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Jim Fulton wrote: >> - It's not well enough documented. While I think there's merit in doing >> some things at the WSGI level, I remain pretty happy with the >> publication interface for separatating generic publisher functions from >> application policies. I which the use of this API was better >> communicated and understood. > > I hope you're not asking me to write documentation for zope.publisher > :-), because I only understand the mechanics. The overall scope and > purpose is cloudy to me. In particular, I don't understand how the > publication interface is actually generic. Does it fit the needs of > anything other than Zope? > >> A less major complaint is some baggage from the past. There are a number >> of request features that I never use and tend to forget about. The >> biggest of these is the special form data unmarshalling and url >> manipulation support. (I was amused to read in your introduction to your >> pipeline proposal that people wanted to know the answer to the question: >> "When does Zope respect the :method form variable?". :) > > FWIW, that particular functionality has been pulled out twice now, both > in repoze.monty and zope.httpform. As a baby step, we could make > zope.publisher depend on zope.httpform. (I made zope.httpform without > knowing repoze.monty already existed, but zope.httpform has more tests > and interfaces and it's hosted on svn.zope.org, so I think zope.httpform > is worth keeping.) Yup. repoze.monty should become just a BBB wrapper. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUNS+gerLs4ltQ4RAlsAAKCQNH3YTAb4NjDq4VOW/ZxU6/pQLgCgzGBW pMIHEqDDxxUno1GdRRx3sEw= =E5aV -END 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] producing a list of packages in the Zope Framework?
Hi. Martijn Faassen wrote: > No volunteers to help produce such a list? Attached you'll find my suggestion for the list. It is based on the Zope2/Plone perspective: Which packages do those two actually use from all the zope.* packages. I suspect the set will initially be a bit larger to accommodate Grok. There is also going to be a set of new packages which should be included over time I guess and a set of packages which should no longer be part of the Zope Framework. This might be a good start however. Hanno Dependencies not part of the Zope Framework ClientForm RestrictedPython ZConfig ZODB3 docutils mechanize pytz setuptools transaction zc.lockfile zdaemon Zope Framework zope.annotation zope.app.applicationcontrol zope.app.appsetup zope.app.authentication zope.app.basicskin zope.app.cache zope.app.component zope.app.container zope.app.debug zope.app.dependable zope.app.exception zope.app.form zope.app.http zope.app.interface zope.app.locales zope.app.pagetemplate zope.app.publication zope.app.publisher zope.app.schema zope.app.security zope.app.testing zope.broken zope.browser zope.cachedescriptors zope.component zope.configuration zope.container zope.contentprovider zope.contenttype zope.copy zope.copypastemove zope.datetime zope.deferredimport zope.deprecation zope.dottedname zope.dublincore zope.error zope.event zope.exceptions zope.filerepresentation zope.formlib zope.hookable zope.i18n zope.i18nmessageid zope.interface zope.lifecycleevent zope.location zope.minmax zope.pagetemplate zope.proxy zope.publisher zope.schema zope.security zope.sendmail zope.sequencesort zope.server zope.session zope.site zope.size zope.structuredtext zope.tal zope.tales zope.testbrowser zope.testing zope.traversing zope.viewlet Parts of the Zope 3.5 KGS not required by Zope 2.12 / Plone 4 zope.catalog zope.decorator zope.documenttemplate zope.file zope.html zope.index zope.intid zope.keyreference zope.mimetype zope.modulealias zope.rdb zope.securitypolicy zope.testrecorder zope.ucol zope.wfmc zope.xmlpickle zope.app.apidoc zope.app.boston zope.app.broken zope.app.catalog zope.app.content zope.app.dav zope.app.debugskin zope.app.dtmlpage zope.app.error zope.app.externaleditor zope.app.file zope.app.folder zope.app.ftp zope.app.generations zope.app.homefolder zope.app.i18n zope.app.i18nfile zope.app.interpreter zope.app.intid zope.app.layers zope.app.locking zope.app.module zope.app.onlinehelp zope.app.pluggableauth zope.app.preference zope.app.preview zope.app.principalannotation zope.app.pythonpage zope.app.renderer zope.app.rotterdam zope.app.securitypolicy zope.app.server zope.app.session zope.app.skins zope.app.sqlscript zope.app.traversing zope.app.tree zope.app.twisted zope.app.undo zope.app.wfmc zope.app.workflow zope.app.wsgi zope.app.xmlrpcintrospection zope.app.zapi zope.app.zcmlfiles zope.app.zopeappgenerations zope.app.zptpage ___ 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
Hey, Dan Korostelev wrote: [snip] > Well, I simply didn't mention the removal of zcml slug, I know that > it's not related to zpkg. Bunch of nitpickers we are. :) Anyway, removing zcml slugs is now official policy. Carry on! Regards, Martijn ___ 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] GSOC 2009
Hey Baiju, Thanks for the reminder. I'm really going to do my best not to get dragged into this again though, so I'm going to stay away from the project. You should try emailing Aroldo though. I just recommend you get a mentor coordinator who gets reports every week from all the mentors and students. Last year's wiki has some guidelines. But even with a mentor coordinator who tried to do a reasonable job last year (me) we had very few projects that made enough progress and we had few students sticking around. Bad luck as definitely a part of this however. Anyway, my time's already overbooked, so I'd rather focus on other things. Regards, Martijn ___ 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.publisher dependencies
Hey, Jim Fulton wrote: [snip] > I'd rather leave zope.publsiher more or less alone, but develop a new > thing that has the basic/core functionality we need and refactor > zope.publisher to use that. I had the impression Shane was doing that; i.e. building zope.pipeline factoring bits out of the publisher but not really changing the publisher very much itself, creating a new structure instead. Shane, is that correct? > I'd also like to use or be compatible > with WebOb on that. I'd prefer to do this at PyCon where I'll have > time to pay attention and where there will be higher bandwidth > communication. +1 on the WebOb compatibility. I imagine it should be possible to reconstruct our request and response interfaces on top of WebOb's. We should also think of ways so that code can get the WebOb request directly instead of having to go through these adapters. I'd also be much in favor of reusing WebOb's implementation, not just the APIs. I think it could help us replace part of the publisher. > I'm sympathetic to Martijn's desire not to slow you down, it's not > clear to me why you need changes to zope.publisher. If it's just a > matter of reducing dependencies, I don't think that's a blocker for > any work you might want to do. Thanks. I'm very much in favor of you guys talking at PyCon if that's the best way to make progress. I'm also looking forward to seeing Shane again at PyCon after meeting him so briefly all these years ago when I was still young and nimble. So I'm glad to hear he's going to make it! I'm also happy I'll get to see you again as well! Regards, Martijn ___ 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] deprecating the deprecation system?
Martijn Faassen wrote: > The deprecation system is a system that is intended to help developers > upgrade their code and that allows us to remove certain deprecated > features after a while. > > * we have quite a few of these developers who are not happy about the > deprecation system. > > * we've been bad at removing deprecated features after a while. > > So I will conclude that from the community perspective the system hasn't > really done its job as well as it should. The system certainly hasn't worked as well as we had hoped. Nonetheless issuing deprecation warnings is not an invention of Zope but Python does this itself. The deprecation warnings you get from Python are most of the times not more than: "X is gonna go away, use Y instead". But you will then go to the upgrade guide or documentation section of the new Python version and look at the new features. Having the focus more on human readable documentation is certainly a good idea. Hanno ___ 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] producing a list of packages in the Zope Framework?
Hey, No volunteers to help produce such a list? Regards, Martijn ___ 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] setup.py "extra" dependencies
On Mar 6, 2009, at 9:50 AM, Martijn Faassen wrote: > Hi there, > > Thanks Gary for sketching our the zc.async usecase. Note that zc.async > isn't in the Zope Framework at this point in time so it wouldn't be > directly affected by this policy, but it's still a useful usecase of > course. Right, that was the intent. ... > * we are going to work at getting rid of the zope.app.testing extra by > distributing its facilities into individual zope.* packages. Hopefully > we can get a clear consensus on this one from the people who object to > the general policy. +1 > * if you think a new "extra" dependency is needed in a Zope Framework > package, and you're not just moving stuff between packages but > actually > developing new code, bring it up on zope-dev so we can at least > consider > alternatives. Perhaps a better home can be found for this code. Fair enough. > * on a case-by-case basis we can consider removing extra dependencies > for particular Zope Framework packages, just like what we're doing > right > now for zope.component. We'll discuss that whenever needed. I'll of > course be biased in favor of such removal, but I can be convinced > otherwise. Fair enough. Thanks Gary ___ 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] the future of ZCML slugs?
On Fri, Mar 6, 2009 at 9:52 AM, Martijn Faassen wrote: > Since nobody spoke up in favor of ZCML slugs, I'm going to record an > official policy they can be removed. +1 -- Benji York Senior Software Engineer 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] the future of ZCML slugs?
Hey, Since nobody spoke up in favor of ZCML slugs, I'm going to record an official policy they can be removed. Regards, Martijn ___ 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] setup.py "extra" dependencies
Hi there, Thanks Gary for sketching our the zc.async usecase. Note that zc.async isn't in the Zope Framework at this point in time so it wouldn't be directly affected by this policy, but it's still a useful usecase of course. We seem to have a split community here... I care about this as it is more easy to see through dependency graphs and reason about circular dependencies when we don't have extra dependencies floating around, and because extras sometimes allow us to hide complicated dependency relationships (such as with zope.app.testing). Since cleaning out dependencies is such an important issue in the Framework I'd like to see less of them... So what about the following proposal then? The intent is to handle this on a case by case basis so we *shrink* the amount of extra dependencies in use within the framework. * we are going to work at getting rid of the zope.app.testing extra by distributing its facilities into individual zope.* packages. Hopefully we can get a clear consensus on this one from the people who object to the general policy. * if you think a new "extra" dependency is needed in a Zope Framework package, and you're not just moving stuff between packages but actually developing new code, bring it up on zope-dev so we can at least consider alternatives. Perhaps a better home can be found for this code. * on a case-by-case basis we can consider removing extra dependencies for particular Zope Framework packages, just like what we're doing right now for zope.component. We'll discuss that whenever needed. I'll of course be biased in favor of such removal, but I can be convinced otherwise. How do people feel about this? Note again it only applies to Framework packages, so shouldn't affect everybody. Regards, Martijn ___ 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] setup.py "extra" dependencies
Hey, Laurence Rowe wrote: [snip] > It seems there is a 'tests_require' One reason that isn't used is that apparently there is no way for us to dig up this information in the way our test runner needs, unlike extras requires. Regards, Martijn ___ 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] deprecating the deprecation system?
Roger Ineichen wrote: > Hi Martijn > >> Betreff: [Zope-dev] deprecating the deprecation system? >> >> Hi there, >> >> Perhaps it's time to deprecate the deprecation system. >> >> Why? >> >> * I've had good experience in the Grok project with just >> noting changes that might break code in the upgrade notes for >> Grok and telling people how to fix it. Using documentation >> more background can be provided and it can become a lot more >> clear what to do. > > It is always good to have such a documentation. But what does > this have to do with removing a deprecation system? It's a tradeoff of burden on developers. In the Zope community we've sometimes assumed a bit too much a developer has infinite time to do a lot of required things when coding. In reality a developer has a limited amount of time and fiddling with the declaration system is so involved such a developer will declare victory. Too early, as good documentation won't get written. I definitely think that something like this has happened in the past; people thought the deprecation system by itself was sufficient and there was no actual documentation with clues about what happened and what to do next. >> * using the deprecation system requires quite a bit of >> effort, as we're adding code. Do we test deprecations? That's >> quite a bit of energy spent there that we could instead spend >> on documentation. > > Yes, a deprecation system requires a lot of effort but that > doesn't mean that the deprecation system is bad or good. > I personaly think it's harder for me to write a good english > documentation in the same time. But that's probably because > I never learned english. So to refer to the above, I'd rather have you spent your effort on writing english documentation than to write deprecations of frequently limited utility. >> * it's a zope-specific system no other Python projects use. >> Now we'll need some of them, but do we need this one? > > We have many things in zope which others don't use. That's no > mesuring base for good or bad It's true that this cannot be the *only* argument. I'll note though that: * we should keep Zope specific things these at a minimum if we can. * this is not the same as, say, the use of zope.interface or zope.component. Those are integral to the code. The deprecation system, like the deferredimport system in most cases, is something that is used that doesn't actually do anything for the user of the package. Instead, it is intended to help developers. Since it's also unfamiliar to other Python developers, this is one more small thing that might make some Python developers turn away from our code. >> * we've not been very good at removing old deprecations over time. > > we can do it better I just wonder why we *haven't* done better already! >> * the deprecation system's messages have traditionally not >> been of a high quality. I recall occasions where it told me >> half of what to do, and certainly won't give me any >> background on what is going on. > > a unclear message is even better then no message That's not the comparison I want to make. An unclear message compared to clear documentation (that describes possible error messages you might get if it's more complicated than an ImportError) is the comparison I intend to make. [snip] > I'm a little bit skeptic about this proposal. And I think no reason > you listed does really explain why the deprecation system is bad. The deprecation system is a system that is intended to help developers upgrade their code and that allows us to remove certain deprecated features after a while. * we have quite a few of these developers who are not happy about the deprecation system. * we've been bad at removing deprecated features after a while. So I will conclude that from the community perspective the system hasn't really done its job as well as it should. Regards, Martijn ___ 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] deprecating the deprecation system?
Hanno Schlichting wrote: [snip interesting analysis] > I'd say that the deprecation system in its current form is well suited > and has worked for the more silent times. It is not suited for covering > the changes of a major new version. I'm not sure it has worked so well. I've seen code in zope.* packages refer to deprecated code in other zope.* packages for a very very long time. I'd also say that we run into the deprecation system *more* in the wild times, such as when Jim refactored the local component registration system. Is a wholesale moving of a class to another place part of the wild times or the quiet times? I'd argue it's more part of the wild times, as a class is rarely moved by itself - the motivation behind this is to more logically arrange the code in packages, and this is something that will touch more than one package. [snip] > Once such a new major version is out, the deprecation system will be > usable again and can cover the more slow paced evolution that will > follow. It's a good tool, but not appropriate for the task at hand. Given the history of its usage in Zope 3 I have my doubts, but perhaps Plone's experience is different and a model we could follow. Regards, Martijn ___ 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.publisher uses deprecated IView
Hey, Wolfgang Schnerring wrote: > since Dan Korostelev commented on my > https://bugs.launchpad.net/zope3/+bug/338136 > saying I should take it to the mailing list, here goes: > > zope.publisher.interfaces.browser.IBrowserView inherits from > zope.component.interfaces.IView, which actually is > zope.component.bbb.interfaces.IView -- marked as deprecated since > 2004, but no pointer what the replacement should be. > > What's going on here? I actually remember running into this many many years ago and got so confused I gave up on it then. :) Hopefully someone else can tell you more! Something is definitely funky in here. I wonder what happens to our compattests if we simply remove this inheritance relationship. If nothing directly refers to IView it might mean everything will still work... Regards, Martijn ___ 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] Stripping down zope.component
Hi there, Tres Seaver wrote: [snip] > Actually, we don't need an upgrade path. We can just leave a > 'meta.zcml' in zope.component which the new locations. That > file will be *inert*, and doesn't therefore need testing, because none > of the directive implementations will be present. > > Over time, people can shift to including the new meta.zcml at their > leisure. We can leave the redirecting meta.zcml in zope.component > *forever*, if need be. It's not just the meta.zcml story, where I can agree we could leave something in place, but it's the dependencies in setup.py, right? If the implementation of the directives lives in zope.componentzcml, any codebase that loads any ZCML at all (in its tests especially) is very likely to need zope.componentzcml besides zope.component. Or am I missing something here? [snip] >> Anyway, this upgrade path needs to be spelled out clearly in the >> zope.component CHANGES.txt pointing people in the right direction. We >> also need to spell it out in this document: >> >> http://svn.zope.org/zope3docs/source/migration/34to35.rst > > Maintaining that document is out of scope for me. ;) If my above story about the dependencies is right, it is necessary to remark this in a central place. We do have framework-wide policies in place, and explaining to people how to unbreak their code in a single place they can look should be one of them. We do after all have people who use a whole bunch of these libraries at the same time. But if you can write it clearly in the CHANGES.txt and tell me, I'll add it to that document if you can't be bothered. Regards, Martijn ___ 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/5 Benji York :
> On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Martijn Faassen wrote:
>>> Baiju M wrote:
On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev wrote:
> 2009/3/2 Tres Seaver :
-
>>> I believe people still use the ZCML "slug" files like the above.
>> They certainly aren't related to 'zpkg'. The intent of the slugs was to
>> allow for something like 'sites-available' / 'sites-enabled' (the
>> pattern in a stock Debian Apache2 install).
>>
>> I think it is particularly unfortunate to remove support for explicit,
>> granular configuration at the same time as folks seem to be jumping to
>> implicit (aka "majyk") tools.
>>
>> Please revert this part of the change.
> I just reverted the change, however, I don't think that the "slug"
> files are useful anymore.
I cannot see similar slugs in other packages either.
>>>
>>> Agreed. I don't understand Tres's or Benji's point either; thanks to
>>> buildout we've left such slugs long behind us I thought. Typically
>>> people would symlink these into an old old installation of Zope 3 (or
>>> copy them over).
>>>
>>> Explicit granular configuration isn't broken at all; if you want to
>>> explicitly include zope.file, you include its configure.zcml, not its
>>> "zope.file-configure.zcml".
>>>
>>> Unless Tres comes back with some convincing explanation soon, please do
>>> get rid of this stuff.
>>
>> Those files exist to allow for a use case we may have abandoned, which
>> is allowing packages to be installed in such a way that a tool could
>> help users enable / disable their configurations, without mutating
>> something like 'site.zcml'. The folks who might have that usecase are
>> those who package zope3 components for deployment outside buildout (as
>> .deb / .rpm, etc.)
>
>> I don't know if there is such an audience; Benji also pointed out that
>> he thought there were such folks.
>
> I don't doubt there are still at least a few, but I also don't think we
> are supporting that use case very well moving forward. We just need to
> make an explicit decision to drop support, and then we can remove the
> slug files.
Can we have an "official desicion from The Steering Group" on that?
>> My initial reaction to Dan's removal
>> was that the checkin message ("remove zpkg stuff") had nothing to do
>> with that particular change: 'zpkg' was entirely separate from slugs.
>
> Same here.
Well, I simply didn't mention the removal of zcml slug, I know that
it's not related to zpkg.
--
WBR, Dan Korostelev
___
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: 6 OK
Summary of messages to the zope-tests list. Period Thu Mar 5 12:00:00 2009 UTC to Fri Mar 6 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: Thu Mar 5 20:22:20 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011235.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:24:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011236.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:26:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011237.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 5 20:28:27 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011238.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Thu Mar 5 20:30:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011239.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Thu Mar 5 20:32:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011240.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 )
[Zope-dev] zope.publisher uses deprecated IView
Hello, since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? Wolfgang -- Wolfgang Schnerring · w...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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.publisher dependencies
Jim Fulton wrote: > I'd rather leave zope.publsiher more or less alone, but develop a new > thing that has the basic/core functionality we need and refactor > zope.publisher to use that. I'd also like to use or be compatible with > WebOb on that. I'd prefer to do this at PyCon where I'll have time to > pay attention and where there will be higher bandwidth communication. I look forward to PyCon! :-) Shane ___ 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.publisher dependencies
On Mar 6, 2009, at 2:18 AM, Shane Hathaway wrote: > Jim Fulton wrote: >> - It's not well enough documented. While I think there's merit in >> doing some things at the WSGI level, I remain pretty happy with the >> publication interface for separatating generic publisher functions >> from application policies. I which the use of this API was better >> communicated and understood. > > I hope you're not asking me to write documentation for > zope.publisher :-), I wasn't asking you to do anything. :) > because I only understand the mechanics. The overall scope and > purpose is cloudy to me. In particular, I don't understand how the > publication interface is actually generic. Does it fit the needs of > anything other than Zope? I believe so. I think there are enough hooks there for pretty much any application. >> A less major complaint is some baggage from the past. There are a >> number of request features that I never use and tend to forget >> about. The biggest of these is the special form data unmarshalling >> and url manipulation support. (I was amused to read in your >> introduction to your pipeline proposal that people wanted to know >> the answer to the question: "When does Zope respect the :method >> form variable?". :) > > FWIW, that particular functionality has been pulled out twice now, > both in repoze.monty and zope.httpform. As a baby step, we could > make zope.publisher depend on zope.httpform. (I made zope.httpform > without knowing repoze.monty already existed, but zope.httpform has > more tests and interfaces and it's hosted on svn.zope.org, so I > think zope.httpform is worth keeping.) I'd rather leave zope.publsiher more or less alone, but develop a new thing that has the basic/core functionality we need and refactor zope.publisher to use that. I'd also like to use or be compatible with WebOb on that. I'd prefer to do this at PyCon where I'll have time to pay attention and where there will be higher bandwidth communication. I'm sympathetic to Martijn's desire not to slow you down, it's not clear to me why you need changes to zope.publisher. If it's just a matter of reducing dependencies, I don't think that's a blocker for any work you might want to do. 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 )
