Hi Tres, I've seen you started some work on Zope2 and its WSGI publisher. This is awesome :) How does this relate to repoze.zope2? I'd love to have Zope2 actually support WSGI out-of-the-box. It should probably be based on either a simplified repoze.zope2 codebase or simply something that gets the job done. So what's your goal with this and is there any way I can help? Thanks, Hanno
On 2009-12-22, at 1627, Hanno Schlichting wrote:
I'd love to have Zope2 actually support WSGI out-of-the-box. It should probably be based on either a simplified repoze.zope2 codebase or simply something that gets the job done.
So what's your goal with this and is there any way I can help?
I'm working on a Plone 4 site running as part of a WSGI stack at the moment. It's using repoze and I've already come across some nasty bugs, so I'd be happy to volunteer time for testing and bugfixing. Matt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Hi Tres,
I've seen you started some work on Zope2 and its WSGI publisher. This is awesome :)
How does this relate to repoze.zope2?
I'd love to have Zope2 actually support WSGI out-of-the-box. It should probably be based on either a simplified repoze.zope2 codebase or simply something that gets the job done.
So what's your goal with this and is there any way I can help?
After a question on the repoze list about running Zope 2.12.x behind a WSGI server, I went to try that out. I came up with a minimal .wsgi file to run behind mod_wsgi:: $ cat src/Zope2/utilities/skel/bin/zope2.wsgi.in from Zope2.Startup.run import configure from Zope2 import startup configure('<<INSTANCE_HOME>>/etc/zope.conf') startup() # mod_wsgi looks for the special name 'application'. from ZPublisher.WSGIPublisher import publish_module as application which works, mostly, except that all the App.ImageFile stuff, as well as anything else using IStreamIterator, doesn't. Streaming output also doesn't work: I'm not sure what else. I set out to fix these bugs in ZPublisher.WSGIPublisher.WSGIResponse, and was dismayed to find it an untested hack-up of the original Publish module, with an untested subclass of HTTPResponse, itself almost completely test-free. So I went down the rabbit hole, and got nearly 100% coverage of HTTPResponse on my branch, along with cleaning out some decade-old fossils. Remaining work would be to write tests for WSGIResponse, and then tweak it (and HTTPResponse) to make doing the Right Thing(TM) possible for responses which are more than just a single big string. Beyond fixing those bugs: - - Document using Zope2 behind mod_wsgi. - - Write a function usable as a PasteDeploy app factory, to allow configuration of Zope2 as the endpoint of a pipeline. Document this feature. - - Supply a stripped-down version of WSGIPublisher, delgating the current implementation's "full stack" behavior (error handling, transaction / retry integration) to middleware. The guts of this can be lifted from repoze.zope2.z2bob. Document using this lighter- weight publisher. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAksxdFgACgkQ+gerLs4ltQ662QCeIyoisFj3ZFwTMGqncyvHWBi5 sTMAnjIpWtTpBJ9zid3BP0n/SIhiDBd0 =Rgs4 -----END PGP SIGNATURE-----
Tres Seaver wrote:
After a question on the repoze list about running Zope 2.12.x behind a WSGI server, I went to try that out. I came up with a minimal .wsgi file to run behind mod_wsgi::
$ cat src/Zope2/utilities/skel/bin/zope2.wsgi.in from Zope2.Startup.run import configure from Zope2 import startup configure('<<INSTANCE_HOME>>/etc/zope.conf') startup() # mod_wsgi looks for the special name 'application'. from ZPublisher.WSGIPublisher import publish_module as application
which works, mostly, except that all the App.ImageFile stuff, as well as anything else using IStreamIterator, doesn't. Streaming output also doesn't work: I'm not sure what else.
That's pretty cool. :) I think people will be a bit confused about the relationship between this and repoze.zope2, though. Maybe we can make a statement about how they differ and whether they ought to be consolidated? As for IStreamIterator, I think it should work to just return the iterator as the WSGI body iterator. At least that works in repoze.zope2.
I set out to fix these bugs in ZPublisher.WSGIPublisher.WSGIResponse, and was dismayed to find it an untested hack-up of the original Publish module, with an untested subclass of HTTPResponse, itself almost completely test-free. So I went down the rabbit hole, and got nearly 100% coverage of HTTPResponse on my branch, along with cleaning out some decade-old fossils.
That's really awesome!
Remaining work would be to write tests for WSGIResponse, and then tweak it (and HTTPResponse) to make doing the Right Thing(TM) possible for responses which are more than just a single big string.
Are there any cases other than IStreamIteartor in that case?
Beyond fixing those bugs:
- - Document using Zope2 behind mod_wsgi.
- - Write a function usable as a PasteDeploy app factory, to allow configuration of Zope2 as the endpoint of a pipeline. Document this feature.
- - Supply a stripped-down version of WSGIPublisher, delgating the current implementation's "full stack" behavior (error handling, transaction / retry integration) to middleware. The guts of this can be lifted from repoze.zope2.z2bob. Document using this lighter- weight publisher.
+lots :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote:
Tres Seaver wrote:
After a question on the repoze list about running Zope 2.12.x behind a WSGI server, I went to try that out. I came up with a minimal .wsgi file to run behind mod_wsgi::
$ cat src/Zope2/utilities/skel/bin/zope2.wsgi.in from Zope2.Startup.run import configure from Zope2 import startup configure('<<INSTANCE_HOME>>/etc/zope.conf') startup() # mod_wsgi looks for the special name 'application'. from ZPublisher.WSGIPublisher import publish_module as application
which works, mostly, except that all the App.ImageFile stuff, as well as anything else using IStreamIterator, doesn't. Streaming output also doesn't work: I'm not sure what else.
That's pretty cool. :)
I think people will be a bit confused about the relationship between this and repoze.zope2, though. Maybe we can make a statement about how they differ and whether they ought to be consolidated?
repoze.zope2 was written to get pre-eggified, pre-WSGI-aware Zope (<=2.11.x) deployable using eggs and Paste. 2.12 is eggified, and speaks a kind of pidgin WSGI; repoze.zope2 is likely still useful, becuase it is more "fluent" in WSGI. See below for futures.
As for IStreamIterator, I think it should work to just return the iterator as the WSGI body iterator. At least that works in repoze.zope2.
I set out to fix these bugs in ZPublisher.WSGIPublisher.WSGIResponse, and was dismayed to find it an untested hack-up of the original Publish module, with an untested subclass of HTTPResponse, itself almost completely test-free. So I went down the rabbit hole, and got nearly 100% coverage of HTTPResponse on my branch, along with cleaning out some decade-old fossils.
That's really awesome!
Remaining work would be to write tests for WSGIResponse, and then tweak it (and HTTPResponse) to make doing the Right Thing(TM) possible for responses which are more than just a single big string.
Are there any cases other than IStreamIteartor in that case?
response.write() is the other one I know about. Getting it to do the Right Thing(TM) under WSGI is going to be tricky, I think.
Beyond fixing those bugs:
- - Document using Zope2 behind mod_wsgi.
- - Write a function usable as a PasteDeploy app factory, to allow configuration of Zope2 as the endpoint of a pipeline. Document this feature.
- - Supply a stripped-down version of WSGIPublisher, delgating the current implementation's "full stack" behavior (error handling, transaction / retry integration) to middleware. The guts of this can be lifted from repoze.zope2.z2bob. Document using this lighter- weight publisher.
If it gets that far by Zope 2.13, then we can likely retire repoze.zope2. Trs. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAksxogAACgkQ+gerLs4ltQ5A1QCgnMpbgP926y5S/vnq6tsht8Tt Lw0An0/MvmhLMF3gJTL6f4wp2hL9gfXV =EKW6 -----END PGP SIGNATURE-----
Tres Seaver wrote:
I set out to fix these bugs in ZPublisher.WSGIPublisher.WSGIResponse, and was dismayed to find it an untested hack-up of the original Publish module, with an untested subclass of HTTPResponse, itself almost completely test-free. So I went down the rabbit hole, and got nearly 100% coverage of HTTPResponse on my branch, along with cleaning out some decade-old fossils.
Many thanks... - C
Hanno Schlichting wrote:
Hi Tres,
I've seen you started some work on Zope2 and its WSGI publisher. This is awesome :)
How does this relate to repoze.zope2?
I'd love to have Zope2 actually support WSGI out-of-the-box. It should probably be based on either a simplified repoze.zope2 codebase or simply something that gets the job done.
So what's your goal with this and is there any way I can help?
I've got a fair amount of experience deploying repoze.zope2 apps (on Zope 2.10/Plone 3.3) and digging around the innards of ZPublisher and repoze.zope2. I think it's important that we get to a WSGI option for Zope 2.13 or 2.14 (for use in Plone 5), so I'm happy to help if I can. Hanno and I spoke about this a while ago. One option would be to have two options: "WSGI" and "Classic" publisher, where the WSGI publisher is only 90% compatible (repoze.zope2 strives for 100%) but 90% more maintainable. If you opt into the WSGI publisher, you may need to forgo relying on some of the more insane parts of the publisher (such as weird things in the request), but you get a more maintainable, better tested and better documented alternative. The old publisher basically stays as-is. We can then fix Zope and Plone to use only the "sane" parts (relatively easy, I think) and let Plone opt into the WSGI publisher. Another thought is to maybe try to make Zope's request compatible with WebOb, which would make it useful for lots of middleware, though that's possibly a bit more radical. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
participants (5)
-
Chris McDonough -
Hanno Schlichting -
Martin Aspeli -
Matthew Wilkes -
Tres Seaver