zope.testbrowser and WebTest (round 2)
I've finally finished refactoring my WebTest/testbrowser branches, basically doing this: - Integrate with WebTest. zope.testbrowser.webtest.Browser is a new Browser implementation that uses webtest.TestApp to drive a WSGI application. This allows simple and direct testing of WSGI applications. - Re-write the test application as a pure WSGI application using WebOb. Run the existing tests using the WebTest based Browser - Move zope.app.testing based Browser into zope.app.testing (leaving backwards compatibility imports in-place). This refactoring removes these test dependencies from zope.testbroswer: zope.app.appsetup zope.app.publication zope.app.testing >= 3.8.1 zope.browserpage zope.browserresource zope.component zope.container zope.principalregistry zope.ptresource zope.publisher zope.security zope.site zope.traversing And adds these: zope.pagetemplate WebTest zope.app.testing gains this dependency: zope.testbrowser >= 4.0.0dev This is a very big change, so I would appreciate anyone who would take a look at these branches before I merge: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser I plan to merge the branches in the next few weeks if there are no objections. -- Brian Sutherland
* Brian Sutherland <brian@vanguardistas.net> [2011-01-30 16:04]:
I've finally finished refactoring my WebTest/testbrowser branches, basically doing this:
- Integrate with WebTest. zope.testbrowser.webtest.Browser is a new Browser implementation that uses webtest.TestApp to drive a WSGI application. This allows simple and direct testing of WSGI applications.
- Re-write the test application as a pure WSGI application using WebOb. Run the existing tests using the WebTest based Browser
- Move zope.app.testing based Browser into zope.app.testing (leaving backwards compatibility imports in-place).
This is a very big change, so I would appreciate anyone who would take a look at these branches before I merge:
Michael Howitz and I recently polished the integration of zope.testbrowser and wsgi_intercept to accomplish pretty much the same things you mentioned. (I'm aware that you two exchanged some emails about it, but don't know any details). So I'm curious: What are the differences bewteen WebTest and wsgi_intercept? Is one preferable to the other? I'd very much like there to be *one* way of doing WSGI with the testbrowser, and at first blush I don't care whether that's WebTest or wsgi_intercept or whathaveyou, as long as it fulfills its purpose. I'll gladly review your branch, but I'd like to know the motivation behind it. Wolfgang
On 2011-1-31 07:02, Wolfgang Schnerring wrote:
* Brian Sutherland<brian@vanguardistas.net> [2011-01-30 16:04]:
I've finally finished refactoring my WebTest/testbrowser branches, basically doing this:
- Integrate with WebTest. zope.testbrowser.webtest.Browser is a new Browser implementation that uses webtest.TestApp to drive a WSGI application. This allows simple and direct testing of WSGI applications.
- Re-write the test application as a pure WSGI application using WebOb. Run the existing tests using the WebTest based Browser
- Move zope.app.testing based Browser into zope.app.testing (leaving backwards compatibility imports in-place).
This is a very big change, so I would appreciate anyone who would take a look at these branches before I merge:
Michael Howitz and I recently polished the integration of zope.testbrowser and wsgi_intercept to accomplish pretty much the same things you mentioned. (I'm aware that you two exchanged some emails about it, but don't know any details).
So I'm curious: What are the differences bewteen WebTest and wsgi_intercept? Is one preferable to the other?
If I remember correctly WebTest wraps the WSGI app object directly and does not require monkeypatching urllib. To send requests to the app under testing you call WebTest post/get methods, which directly call the WSGI app. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
* Brian Sutherland <brian@vanguardistas.net> [2011-01-30 16:04]:
I've finally finished refactoring my WebTest/testbrowser branches, basically doing this:
- Integrate with WebTest. zope.testbrowser.webtest.Browser is a new Browser implementation that uses webtest.TestApp to drive a WSGI application. This allows simple and direct testing of WSGI applications.
- Re-write the test application as a pure WSGI application using WebOb. Run the existing tests using the WebTest based Browser
- Move zope.app.testing based Browser into zope.app.testing (leaving backwards compatibility imports in-place).
This is a very big change, so I would appreciate anyone who would take a look at these branches before I merge:
Michael Howitz and I recently polished the integration of zope.testbrowser and wsgi_intercept to accomplish pretty much the same things you mentioned. (I'm aware that you two exchanged some emails about it, but don't know any details).
So I'm curious: What are the differences bewteen WebTest and wsgi_intercept? Is one preferable to the other?
The differences I've seen between the two libraries: * WebTest doesn't require a global setup/teardown. (no zope.testing Layer dependency) * With WebTest it's more difficult to accidentally end up sending real HTTP requests over the internet. I'm probably missing quite a few though. Another interesting datapoint is the number of downloads of each package from pypi.python.org: * http://pypi.python.org/pypi/wsgi_intercept/0.4 13000 downloads in 2 years * http://pypi.python.org/pypi/WebTest/1.2.3 18500 downloads in 2 months
I'd very much like there to be *one* way of doing WSGI with the testbrowser, and at first blush I don't care whether that's WebTest or wsgi_intercept or whathaveyou, as long as it fulfills its purpose.
We have already committed to wsgi_intercept integration for the long term. It was released in zope.testbrowser 3.11 a few days ago, right? If we are to have only one way to do this, then wsgi_intercept must be it. But I'm ambivalent about only having one way to do things. I think having both integrations in zope.testbrowser is not such a bad thing. Having the test suite run over 2 different integrations is definitely good.
I'll gladly review your branch, but I'd like to know the motivation behind it.
Only ~30% of the branch is the implementation of the WebTest connection. The other ~70% of the branch is a refactoring of the test suite. That's where the reduction in test dependencies comes from. The test fixture on the branch is a reasonably minimal WSGI application run via the WebTest connection. Attached is a patch for my branch to run the test suite with the wsgi_intercept integration. I havn't committed it yet as it has multiple failures. A way forward may be to fix the wsgi_intercept integration so that it can run the full test suite then merge my branch without the WebTest integration. However I would prefer to merge the WebTest integration as is and fix the wsgi_intercept integration.
Wolfgang
_______________________________________________ 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 )
-- Brian Sutherland
* Wichert Akkerman <wichert@wiggy.net> [2011-01-31 09:46]:
On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
So I'm curious: What are the differences bewteen WebTest and wsgi_intercept? Is one preferable to the other?
If I remember correctly WebTest wraps the WSGI app object directly and does not require monkeypatching urllib. To send requests to the app under testing you call WebTest post/get methods, which directly call the WSGI app.
Thanks for clarifying, that does indeed make sense. I guess I should have researched wsgi_intercept and WebTest in more detail. :/ * Brian Sutherland <brian@vanguardistas.net> [2011-01-31 09:54]:
On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
I'd very much like there to be *one* way of doing WSGI with the testbrowser, and at first blush I don't care whether that's WebTest or wsgi_intercept or whathaveyou, as long as it fulfills its purpose.
We have already committed to wsgi_intercept integration for the long term. It was released in zope.testbrowser 3.11 a few days ago, right? If we are to have only one way to do this, then wsgi_intercept must be it.
I definitely don't see this as set in stone, *at all*. Yes, we've had a release that uses wsgi_intercept for talking to WSGI apps. (And yes, we didn't ask anyone for their opinion on it, and I'm sorry about that. However, I guess the development process in the Zope community is an entirely different issue, sigh.) But I feel the important point about this regarding compatibility is not the underlying technology, but the API, i. e. that - zope.testbrowser.wsgi.Browser is a Testbrowser - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to facilitate the test setup. I think as long as we preserve this API (which seems sound to me, but of course I'm biased ;-), we're free to change stuff under the hood.
But I'm ambivalent about only having one way to do things. I think having both integrations in zope.testbrowser is not such a bad thing. Having the test suite run over 2 different integrations is definitely good.
Maybe I'm missing something, but when I think about the task at hand from the client's perspective, then the only sentence that matters to me is, "give me a zope.testbrowser that talks to this WSGI callable". Which means a) I couldn't care less how that's done internally as long as it doesn't cause me any hassle and, more importantly b) I do *not* want to have to think about it and/or make a choice about the underlying mechanism. I want the library to have done that research (as we are doing right now). And to me this task seems straightforward enough to not warrant pluggability -- on the contrary, I feel it's so narrow in scope it outright *forbids* it (but again, I may be missing something).
I'll gladly review your branch, but I'd like to know the motivation behind it.
Only ~30% of the branch is the implementation of the WebTest connection.
The other ~70% of the branch is a refactoring of the test suite. That's where the reduction in test dependencies comes from. The test fixture on the branch is a reasonably minimal WSGI application run via the WebTest connection.
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest b) extract the testbrowser part that talks to the Publisher As to (a), I'll still need to look at your code, but as I said I'm all in favour of using WebTest instead of wsgi_intercept. As to (b), I saw you moved the code to zope.app.testing. I have a few ideas in that area which I'll contact you off-list about. Wolfgang
On Tue, Feb 1, 2011 at 3:32 AM, Wolfgang Schnerring <ws@gocept.com> wrote:
But I feel the important point about this regarding compatibility is not the underlying technology, but the API, i. e. that - zope.testbrowser.wsgi.Browser is a Testbrowser - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to facilitate the test setup.
I think as long as we preserve this API (which seems sound to me, but of course I'm biased ;-), we're free to change stuff under the hood.
+1 Compatibility is key. Note however that it's also harder than it looks, so gratuitous change will often bite you. That being said, I think you're on the right track here. -- Benji York
On Tuesday, February 01, 2011, Wolfgang Schnerring wrote:
But I feel the important point about this regarding compatibility is not the underlying technology, but the API, i. e. that - zope.testbrowser.wsgi.Browser is a Testbrowser - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to facilitate the test setup.
I think as long as we preserve this API (which seems sound to me, but of course I'm biased ;-), we're free to change stuff under the hood.
+1 Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
* Brian Sutherland <brian@vanguardistas.net> [2011-01-31 09:54]:
On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
I'd very much like there to be *one* way of doing WSGI with the testbrowser, and at first blush I don't care whether that's WebTest or wsgi_intercept or whathaveyou, as long as it fulfills its purpose.
We have already committed to wsgi_intercept integration for the long term. It was released in zope.testbrowser 3.11 a few days ago, right? If we are to have only one way to do this, then wsgi_intercept must be it.
I definitely don't see this as set in stone, *at all*. Yes, we've had a release that uses wsgi_intercept for talking to WSGI apps. (And yes, we didn't ask anyone for their opinion on it, and I'm sorry about that. However, I guess the development process in the Zope community is an entirely different issue, sigh.)
Yeah, a totally different issue that I don't really wanna get involved in right now.
But I feel the important point about this regarding compatibility is not the underlying technology, but the API, i. e. that - zope.testbrowser.wsgi.Browser is a Testbrowser - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to facilitate the test setup.
I think as long as we preserve this API (which seems sound to me, but of course I'm biased ;-), we're free to change stuff under the hood.
Ok, I think that that API is preservable. However I would like to make the layer optional by adding an wsgi_app keyword argument to Browser. So you can do: >>> browser = Browser(wsgi_app=app) where app is a WSGI application. Some people in the non-zope world are not too fond of layers, or use incompatible testrunners. We shouldn't force layers on them.
But I'm ambivalent about only having one way to do things. I think having both integrations in zope.testbrowser is not such a bad thing. Having the test suite run over 2 different integrations is definitely good.
Maybe I'm missing something, but when I think about the task at hand from the client's perspective, then the only sentence that matters to me is, "give me a zope.testbrowser that talks to this WSGI callable".
Which means a) I couldn't care less how that's done internally as long as it doesn't cause me any hassle and, more importantly b) I do *not* want to have to think about it and/or make a choice about the underlying mechanism. I want the library to have done that research (as we are doing right now). And to me this task seems straightforward enough to not warrant pluggability -- on the contrary, I feel it's so narrow in scope it outright *forbids* it (but again, I may be missing something).
Well, it appears that now we've reached some sort of consensus as to what base library to use. So yeah, having *one* way to do things is just fine.
I'll gladly review your branch, but I'd like to know the motivation behind it.
Only ~30% of the branch is the implementation of the WebTest connection.
The other ~70% of the branch is a refactoring of the test suite. That's where the reduction in test dependencies comes from. The test fixture on the branch is a reasonably minimal WSGI application run via the WebTest connection.
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest b) extract the testbrowser part that talks to the Publisher
Initially I did them together because it was the only way to get very good test coverage of the WebTest integration. If we do it this way, between steps a and b we'll have poor coverate. But that's not so bad as the code has already been well tested on my current branch.
As to (a), I'll still need to look at your code, but as I said I'm all in favour of using WebTest instead of wsgi_intercept.
I'll try make a branch for this in the next week or so for you to review.
As to (b), I saw you moved the code to zope.app.testing. I have a few ideas in that area which I'll contact you off-list about.
Sure!
Wolfgang
_______________________________________________ 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 )
-- Brian Sutherland
On Wed, Feb 02, 2011 at 11:15:19AM +0100, Brian Sutherland wrote:
Ok, I think that that API is preservable. However I would like to make the layer optional by adding an wsgi_app keyword argument to Browser. So you can do:
>>> browser = Browser(wsgi_app=app)
where app is a WSGI application.
+1
Some people in the non-zope world are not too fond of layers, or use incompatible testrunners. We shouldn't force layers on them.
+1 Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
Hi, sorry I'm replying this late. I've been busy, then sick, then busy again, so I'm afraid this has got pushed low on my stack of stuff... * Brian Sutherland <brian@vanguardistas.net> [2011-02-02 11:15]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
* Brian Sutherland <brian@vanguardistas.net> [2011-01-31 09:54]:
On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote: Ok, I think that that API is preservable. However I would like to make the layer optional by adding an wsgi_app keyword argument to Browser. So you can do:
>>> browser = Browser(wsgi_app=app)
where app is a WSGI application.
Some people in the non-zope world are not too fond of layers, or use incompatible testrunners. We shouldn't force layers on them.
Yes, we definitely don't want to require layers here. This has not been an issue so far, since both the publisher and the wsgi_intercept method inject the application to the browser by looking it up via the special hostname 'localhost', but now we need to pass in the WSGI callable explicitly. I do think that mostly one will want to prepare the WSGI callable only once, and thus a layer is a good fit, but that should be optional.
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest b) extract the testbrowser part that talks to the Publisher
Initially I did them together because it was the only way to get very good test coverage of the WebTest integration. If we do it this way, between steps a and b we'll have poor coverate. But that's not so bad as the code has already been well tested on my current branch.
As to (a), I'll still need to look at your code, but as I said I'm all in favour of using WebTest instead of wsgi_intercept.
I'll try make a branch for this in the next week or so for you to review.
Thanks very much, I'll look throught it as soon as I find some time, probably not next week (I'm travelling), but hopefully the week after that, at the latest.
As to (b), I saw you moved the code to zope.app.testing. I have a few ideas in that area which I'll contact you off-list about. Sure!
As we've discussed off-list, we now both feel that moving the publisher-testbrowser to zope.app.testing is a good idea, since the only applications that will want to use that testbrowser are those that use zope.app.testing -- the more modern approach of testing publisher-based applications is to use the code from zope.app.wsgi to create a WSGI application and then use the WSGI-enabled testbrowser to talk to that. Wolfgang
On Sat, Feb 12, 2011 at 02:59:50PM +0100, Wolfgang Schnerring wrote:
Hi,
sorry I'm replying this late. I've been busy, then sick, then busy again, so I'm afraid this has got pushed low on my stack of stuff...
No worries, I'm not in a big rush :)
* Brian Sutherland <brian@vanguardistas.net> [2011-02-02 11:15]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
* Brian Sutherland <brian@vanguardistas.net> [2011-01-31 09:54]: I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal The test coverage on this branch leaves much to be desired.
b) extract the testbrowser part that talks to the Publisher
This is here and by necessity includes the changes for step (a): svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser I would much prefer to merge both steps together.
Initially I did them together because it was the only way to get very good test coverage of the WebTest integration. If we do it this way, between steps a and b we'll have poor coverate. But that's not so bad as the code has already been well tested on my current branch.
As to (a), I'll still need to look at your code, but as I said I'm all in favour of using WebTest instead of wsgi_intercept.
I'll try make a branch for this in the next week or so for you to review.
Thanks very much, I'll look throught it as soon as I find some time, probably not next week (I'm travelling), but hopefully the week after that, at the latest.
Sure, I can wait a few weeks. But let me know if you're not going to get around to it.
As to (b), I saw you moved the code to zope.app.testing. I have a few ideas in that area which I'll contact you off-list about. Sure!
As we've discussed off-list, we now both feel that moving the publisher-testbrowser to zope.app.testing is a good idea, since the only applications that will want to use that testbrowser are those that use zope.app.testing -- the more modern approach of testing publisher-based applications is to use the code from zope.app.wsgi to create a WSGI application and then use the WSGI-enabled testbrowser to talk to that.
Great, looks like we have a consensus :) -- Brian Sutherland
Hello Brian, it's taken a while, but I finally had a chance to review your branch(es). * Brian Sutherland <brian@vanguardistas.net> [2011-02-12 18:57]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal
Thanks, that helped me understand what's going on much better. I do have a few questions about this part: - Does the (webtest-based) wsgi.Browser behave similarly to the Publisher-Browser? When we ported the wsgi_intercept variant from zope.app.wsgi, we found that there were some idiosyncracies woven in that people may rely on. This kind of stuff of course isn't documented, and we didn't do much research, but rather took care to port what we found in zope.app.wsgi, namely filtering some HTTP headers from the response (meh, doesn't feel important), and handling Basic Auth headers (that feels important to preserve). - What should happen in zope.app.wsgi? We moved the wsgi-based Testbrowser from there and left BBB imports to zope.testbrowser.wsgi, taking care to be API compatible. I guess that won't be possible with the WebTest-based Testbrowser (or would it?), so we probably have to break that. (Hmm, would that imply a major version bump there, too?) Since the Grok people are the ones who probably use the zope.app.wsgi Testbrowser the most, they should probably take the WebTest-Testbrowser for a test drive and see whether it works for them, otherwise we're going to make them quite unhappy if we just break zope.app.wsgi. (Could you ask on grok-dev about that? I guess it's too buried here to be noticed.) - What's connection.py? I don't really understand where that came from or what its purpose is, especially since wsgi.py seems to be the only one that uses it? Ah. I take that last bit back, the extracted Publisher-Browser in zope.app.testing uses it, so I guess this is a split-off artifact of the refactoring/extraction. But I still don't really understand what it is all about. %-) - The layer looks good. (OK, so that's not a question ;) I'm glad you found a way that the browser can get the application "out of the air". I've tried the explicit passing way on a project of mine, and it's a huge hassle (I've ended up stuffing a preconfigured browser instance into the doctest globs, ugh.) I think it would be good if the layer stored the application of self.app, we did that in the wsgi_intercept variant and were glad of it a few times already.
b) extract the testbrowser part that talks to the Publisher
This is here and by necessity includes the changes for step (a): svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser
The extraction of the Publisher-Browser makes a lot of sense, and looks clean to me, as does the rewrite of the tests to use a plain WSGI app instead of a Zope-based app.
I would much prefer to merge both steps together.
Yes, I guess that makes sense because only step (b) includes proper tests for everything. Wolfgang
On Wed, 02 Mar 2011 09:16:14 +0100 Wolfgang Schnerring <ws@gocept.com> wrote:
Hello Brian,
Hello,
it's taken a while, but I finally had a chance to review your branch(es).
* Brian Sutherland <brian@vanguardistas.net> [2011-02-12 18:57]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal
Thanks, that helped me understand what's going on much better.
I do have a few questions about this part:
- Does the (webtest-based) wsgi.Browser behave similarly to the Publisher-Browser?
When we ported the wsgi_intercept variant from zope.app.wsgi, we found that there were some idiosyncracies woven in that people may rely on. This kind of stuff of course isn't documented, and we didn't do much research, but rather took care to port what we found in zope.app.wsgi, namely filtering some HTTP headers from the response (meh, doesn't feel important), and handling Basic Auth headers (that feels important to preserve).
Don't forget the support to do handleErrors = False. It is I think one of the most important, which help to debug the tests. In zope.app.wsgi all those idiosyncracies are more or less handled by a WSGI middleware. I guess you can reuse it. One of the purpose of the zope.app.wsgi implementation was to be able to convert the existing tests just by changing the import, and get ride of zope.testbrowser dependencies on the crazy zope.app.testing nobody-knows-what-it-does-and-does-everything in Grok (without adding many others). Which worked perfectly. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
On Thu, Mar 03, 2011 at 11:04:12AM +0100, Sylvain Viollon wrote:
On Wed, 02 Mar 2011 09:16:14 +0100 Wolfgang Schnerring <ws@gocept.com> wrote:
Hello Brian,
Hello,
it's taken a while, but I finally had a chance to review your branch(es).
* Brian Sutherland <brian@vanguardistas.net> [2011-02-12 18:57]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal
Thanks, that helped me understand what's going on much better.
I do have a few questions about this part:
- Does the (webtest-based) wsgi.Browser behave similarly to the Publisher-Browser?
When we ported the wsgi_intercept variant from zope.app.wsgi, we found that there were some idiosyncracies woven in that people may rely on. This kind of stuff of course isn't documented, and we didn't do much research, but rather took care to port what we found in zope.app.wsgi, namely filtering some HTTP headers from the response (meh, doesn't feel important), and handling Basic Auth headers (that feels important to preserve).
Don't forget the support to do handleErrors = False. It is I think one of the most important, which help to debug the tests.
That's supported for both zope.app.wsgi and Paste applications. YMMV for other WSGI applications.
In zope.app.wsgi all those idiosyncracies are more or less handled by a WSGI middleware. I guess you can reuse it.
One of the purpose of the zope.app.wsgi implementation was to be able to convert the existing tests just by changing the import, and get ride of zope.testbrowser dependencies on the crazy zope.app.testing nobody-knows-what-it-does-and-does-everything in Grok (without adding many others). Which worked perfectly.
I'll definitely look into reusing the middleware. But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required)
Regards,
Sylvain,
-- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands _______________________________________________ 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 )
-- Brian Sutherland
Hello, On Fri, 4 Mar 2011 10:15:18 +0100 Brian Sutherland <brian@vanguardistas.net> wrote:
In zope.app.wsgi all those idiosyncracies are more or less handled by a WSGI middleware. I guess you can reuse it.
One of the purpose of the zope.app.wsgi implementation was to be able to convert the existing tests just by changing the import, and get ride of zope.testbrowser dependencies on the crazy zope.app.testing nobody-knows-what-it-does-and-does-everything in Grok (without adding many others). Which worked perfectly.
I'll definitely look into reusing the middleware.
But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required)
There is a Grok ToolKit, that works exactly like the Zope ToolKit: http://svn.zope.org/groktoolkit/trunk If you run this buildout you should get a ./bin/test-grok command that runs all the tests, using z3c.recipe.compattest. Actually, I think you can start by testing only grokcore.view. I guess it is one of the base packages that uses a lot the test browser. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote:
Hello,
On Fri, 4 Mar 2011 10:15:18 +0100 Brian Sutherland <brian@vanguardistas.net> wrote:
In zope.app.wsgi all those idiosyncracies are more or less handled by a WSGI middleware. I guess you can reuse it.
One of the purpose of the zope.app.wsgi implementation was to be able to convert the existing tests just by changing the import, and get ride of zope.testbrowser dependencies on the crazy zope.app.testing nobody-knows-what-it-does-and-does-everything in Grok (without adding many others). Which worked perfectly.
I'll definitely look into reusing the middleware.
But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required)
There is a Grok ToolKit, that works exactly like the Zope ToolKit:
http://svn.zope.org/groktoolkit/trunk
If you run this buildout you should get a ./bin/test-grok command that runs all the tests, using z3c.recipe.compattest.
Actually, I think you can start by testing only grokcore.view. I guess it is one of the base packages that uses a lot the test browser.
Ok, there are 2 grokcore.view failures with my branch. The first is due to the Basic Auth header and is fixable by adding the middleware we were talking about. The other is more interesting, in src/grokcore/view/ftests/url/redirect.py. It seems that that test is actually making calls over the network to google's servers. Probably not a good thing. The new behaviour (probably not good either) is to send the request to the application even if the hostname is "www.google.com". I would guess that the right behaviour would be to raise an error if the hostname is not "localhost" or 127.0.0.1.
Regards,
Sylvain,
-- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
-- Brian Sutherland
Hello from the grok department, On 4 March 2011 11:48, Brian Sutherland <brian@vanguardistas.net> wrote:
On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote:
Hello,
On Fri, 4 Mar 2011 10:15:18 +0100 Brian Sutherland <brian@vanguardistas.net> wrote:
In zope.app.wsgi all those idiosyncracies are more or less handled by a WSGI middleware. I guess you can reuse it.
One of the purpose of the zope.app.wsgi implementation was to be able to convert the existing tests just by changing the import, and get ride of zope.testbrowser dependencies on the crazy zope.app.testing nobody-knows-what-it-does-and-does-everything in Grok (without adding many others). Which worked perfectly.
I'll definitely look into reusing the middleware.
But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required)
There is a Grok ToolKit, that works exactly like the Zope ToolKit:
http://svn.zope.org/groktoolkit/trunk
If you run this buildout you should get a ./bin/test-grok command that runs all the tests, using z3c.recipe.compattest.
Actually, I think you can start by testing only grokcore.view. I guess it is one of the base packages that uses a lot the test browser.
Ok, there are 2 grokcore.view failures with my branch.
The first is due to the Basic Auth header and is fixable by adding the middleware we were talking about.
To get the groktoolkit tests and my company's applications to run with Brian's zope.testbrowser+webtest branch I did the following things: * I created a branch of zope.app.wsgi trunk [1] to which I copied the AuthorizationMiddleware from zope.testbrowser trunk (moved there in [2]). The three middleware components (Transaction, Authorization and HandleErrors) are needed to make the groktoolkit tests pass. The AuthorizationMiddleware is not available on Brian's branch, but is available on zope.testbrowser trunk. If we can land this middleware in zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer. In my opinion, this middleware should be part of zope.testbrowser, because handleErrors is part of the IBrowser interface. * The `http caller` in zope.app.wsgi.testlayer is used in grokcore.rest. On my branch, I rewrote the http caller to use WebTest and _APP_UNDER_TEST instead of wsgi_intercept. The import from zope.testbrowser is bothering me; can we put the http caller in zope.testbrowser? The http caller returns a FakeResponse instance, which could very well be a WebTest TestResponse. The FakeResponse wrapper is merely used to fix the current tests. * I fixed some tests in grok and grokcore.rest to use the WebTest-style http caller.
The other is more interesting, in src/grokcore/view/ftests/url/redirect.py. It seems that that test is actually making calls over the network to google's servers. Probably not a good thing.
The new behaviour (probably not good either) is to send the request to the application even if the hostname is "www.google.com".
I would guess that the right behaviour would be to raise an error if the hostname is not "localhost" or 127.0.0.1.
+1 In order to run the tests on the groktoolkit trunk, run: bin/buildout sources:zope.testbrowser="svn svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3" sources:zope.app.wsgi="svn svn+ssh://svn.zope.org/repos/main/zope.app.wsgi/branches/janjaapdriessen-webtest" buildout:auto-checkout="zope.testbrowser zope.app.wsgi grok grokcore.rest" versions:WebTest=1.2.3 && bin/test-grok -- Jan-Jaap Driessen 1) http://zope3.pov.lt/trac/changeset/120756/zope.app.wsgi/branches/janjaapdrie... 2) http://zope3.pov.lt/trac/changeset/119878/zope.app.wsgi/trunk/src/zope/app/w...
On Sat, Mar 05, 2011 at 01:07:58AM +0100, Jan-Jaap Driessen wrote:
Hello from the grok department,
On 4 March 2011 11:48, Brian Sutherland <brian@vanguardistas.net> wrote:
On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote:
Hello,
On Fri, 4 Mar 2011 10:15:18 +0100 Brian Sutherland <brian@vanguardistas.net> wrote:
In zope.app.wsgi all those idiosyncracies are more or less handled by a WSGI middleware. I guess you can reuse it.
One of the purpose of the zope.app.wsgi implementation was to be able to convert the existing tests just by changing the import, and get ride of zope.testbrowser dependencies on the crazy zope.app.testing nobody-knows-what-it-does-and-does-everything in Grok (without adding many others). Which worked perfectly.
I'll definitely look into reusing the middleware.
But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required)
There is a Grok ToolKit, that works exactly like the Zope ToolKit:
http://svn.zope.org/groktoolkit/trunk
If you run this buildout you should get a ./bin/test-grok command that runs all the tests, using z3c.recipe.compattest.
Actually, I think you can start by testing only grokcore.view. I guess it is one of the base packages that uses a lot the test browser.
Ok, there are 2 grokcore.view failures with my branch.
The first is due to the Basic Auth header and is fixable by adding the middleware we were talking about.
To get the groktoolkit tests and my company's applications to run with Brian's zope.testbrowser+webtest branch I did the following things:
Great, thanks a lot!!!
* I created a branch of zope.app.wsgi trunk [1] to which I copied the AuthorizationMiddleware from zope.testbrowser trunk (moved there in [2]). The three middleware components (Transaction, Authorization and HandleErrors) are needed to make the groktoolkit tests pass. The AuthorizationMiddleware is not available on Brian's branch
I've added the AuthorizationMiddleware to zope.testbrowser.wsgi and added some tests for it. It doesn't look like it'll be much of a maintenance headache being very simple with no dependencies.
, but is available on zope.testbrowser trunk. If we can land this middleware in zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer. In my opinion, this middleware should be part of zope.testbrowser, because handleErrors is part of the IBrowser interface.
Hmm, the TransactionMiddleware looks very app-specific, as does the HandleErrorsMiddleware. In fact, I think you'll find that with my branch the HandleErrorsMiddleware is a no-op and can be removed. The 'wsgi.handleErrors' environment variable is set in zope.testbrowser.wsgi directly now.
* The `http caller` in zope.app.wsgi.testlayer is used in grokcore.rest. On my branch, I rewrote the http caller to use WebTest and _APP_UNDER_TEST instead of wsgi_intercept. The import from zope.testbrowser is bothering me; can we put the http caller in zope.testbrowser? The http caller returns a FakeResponse instance, which could very well be a WebTest TestResponse. The FakeResponse wrapper is merely used to fix the current tests.
I see. I think the layer just needs to become better about exposing the global application under test. I've just committed a patch to make the .app property a get_app classmethod. So you can do: global_app_under_test = zope.testbrowser.wsgi.Layer.get_app() rather than access _APP_UNDER_TEST directly. I'd rather not move the http caller to zope.testbrowser as I'm not sure what functionality it provides over just using webtest.TestApp directly.
* I fixed some tests in grok and grokcore.rest to use the WebTest-style http caller.
The other is more interesting, in src/grokcore/view/ftests/url/redirect.py. It seems that that test is actually making calls over the network to google's servers. Probably not a good thing.
The new behaviour (probably not good either) is to send the request to the application even if the hostname is "www.google.com".
I would guess that the right behaviour would be to raise an error if the hostname is not "localhost" or 127.0.0.1.
+1
Ok, committed this. I've also allowed domains like test.example.com.
In order to run the tests on the groktoolkit trunk, run:
bin/buildout sources:zope.testbrowser="svn svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3" sources:zope.app.wsgi="svn svn+ssh://svn.zope.org/repos/main/zope.app.wsgi/branches/janjaapdriessen-webtest" buildout:auto-checkout="zope.testbrowser zope.app.wsgi grok grokcore.rest" versions:WebTest=1.2.3 && bin/test-grok
-- Jan-Jaap Driessen
1) http://zope3.pov.lt/trac/changeset/120756/zope.app.wsgi/branches/janjaapdrie... 2) http://zope3.pov.lt/trac/changeset/119878/zope.app.wsgi/trunk/src/zope/app/w...
-- Brian Sutherland
On Sat, Mar 05, 2011 at 01:07:58AM +0100, Jan-Jaap Driessen wrote:
To get the groktoolkit tests and my company's applications to run with Brian's zope.testbrowser+webtest branch I did the following things:
* I created a branch of zope.app.wsgi trunk [1] to which I copied the AuthorizationMiddleware from zope.testbrowser trunk (moved there in [2]). The three middleware components (Transaction, Authorization and HandleErrors) are needed to make the groktoolkit tests pass. The AuthorizationMiddleware is not available on Brian's branch, but is available on zope.testbrowser trunk. If we can land this middleware in zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer. In my opinion, this middleware should be part of zope.testbrowser, because handleErrors is part of the IBrowser interface.
* The `http caller` in zope.app.wsgi.testlayer is used in grokcore.rest. On my branch, I rewrote the http caller to use WebTest and _APP_UNDER_TEST instead of wsgi_intercept. The import from zope.testbrowser is bothering me; can we put the http caller in zope.testbrowser? The http caller returns a FakeResponse instance, which could very well be a WebTest TestResponse. The FakeResponse wrapper is merely used to fix the current tests.
* I fixed some tests in grok and grokcore.rest to use the WebTest-style http caller.
I was pretty sure you wouldn't mind so I committed a few cleanups and bugfixes to your zope.app.wsgi branch. The trunk ztk and zopeapp tests now also pass with the three branches. -- Brian Sutherland
On Wed, Mar 02, 2011 at 09:16:14AM +0100, Wolfgang Schnerring wrote:
Hello Brian,
it's taken a while, but I finally had a chance to review your branch(es).
Great!
* Brian Sutherland <brian@vanguardistas.net> [2011-02-12 18:57]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal
Thanks, that helped me understand what's going on much better.
I do have a few questions about this part:
- Does the (webtest-based) wsgi.Browser behave similarly to the Publisher-Browser?
When we ported the wsgi_intercept variant from zope.app.wsgi, we found that there were some idiosyncracies woven in that people may rely on. This kind of stuff of course isn't documented, and we didn't do much research, but rather took care to port what we found in zope.app.wsgi, namely filtering some HTTP headers from the response (meh, doesn't feel important), and handling Basic Auth headers (that feels important to preserve).
I feel strongly that these idiosyncrasies shouldn't get built into the new WSGI testbrowser and perpetuated. You had some WSGI middleware which implemented these. I think we can do it in the same way and anyone migrating from Publisher-Browser based code could use it. Perhaps that needs to be inside zope.testbrowser itself, or could be done in zope.app.wsgi. Depends on the details I guess. Unfortunately, as you say, they are undocumented and seem to be untested. I would like to make a deeper investigation of those issues and write some tests. Is there any test suite (grok perhaps?) that I can run using the new WSGI based browser that'll highlight these issues?
- What should happen in zope.app.wsgi?
We moved the wsgi-based Testbrowser from there and left BBB imports to zope.testbrowser.wsgi, taking care to be API compatible. I guess that won't be possible with the WebTest-based Testbrowser (or would it?), so we probably have to break that. (Hmm, would that imply a major version bump there, too?)
Since the Grok people are the ones who probably use the zope.app.wsgi Testbrowser the most, they should probably take the WebTest-Testbrowser for a test drive and see whether it works for them, otherwise we're going to make them quite unhappy if we just break zope.app.wsgi. (Could you ask on grok-dev about that? I guess it's too buried here to be noticed.)
I'll try to co-ordinate with the grok/zope.app.wsgi developers on this. I was unaware that they had BBB imports from zope.testbrowser.
- What's connection.py?
I don't really understand where that came from or what its purpose is, especially since wsgi.py seems to be the only one that uses it?
Ah. I take that last bit back, the extracted Publisher-Browser in zope.app.testing uses it, so I guess this is a split-off artifact of the refactoring/extraction.
But I still don't really understand what it is all about. %-)
It's about minimizing the duplicated code in zope.app.testing.testbrowser and zope.testbrowser.wsgi. It's kind of "reusable pieces to build zope.testbrowser connections". That said, I'm uncomfortable with it. connection.py is probably not really very reusable. And anyone changing it would have to be aware that it was reused in zope.app.testing. Another way would be to fold connection.py into zope.testbrowser.wsgi and copy the necessary code to zope.app.testing. It's not obvious to me which way is better. You could easily persuade me another way is better.
- The layer looks good. (OK, so that's not a question ;)
I'm glad you found a way that the browser can get the application "out of the air". I've tried the explicit passing way on a project of mine, and it's a huge hassle (I've ended up stuffing a preconfigured browser instance into the doctest globs, ugh.)
yeah, in the end wsgi_intercept uses global variables. So it's the same approach.
I think it would be good if the layer stored the application of self.app, we did that in the wsgi_intercept variant and were glad of it a few times already.
Sure, I've added that.
b) extract the testbrowser part that talks to the Publisher
This is here and by necessity includes the changes for step (a): svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser
The extraction of the Publisher-Browser makes a lot of sense, and looks clean to me, as does the rewrite of the tests to use a plain WSGI app instead of a Zope-based app.
Great!
I would much prefer to merge both steps together.
Yes, I guess that makes sense because only step (b) includes proper tests for everything.
Perfect.
Wolfgang
_______________________________________________ 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 )
-- Brian Sutherland
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week. Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself) On Wed, Mar 02, 2011 at 09:16:14AM +0100, Wolfgang Schnerring wrote:
Hello Brian,
it's taken a while, but I finally had a chance to review your branch(es).
* Brian Sutherland <brian@vanguardistas.net> [2011-02-12 18:57]:
On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal
Thanks, that helped me understand what's going on much better.
I do have a few questions about this part:
- Does the (webtest-based) wsgi.Browser behave similarly to the Publisher-Browser?
When we ported the wsgi_intercept variant from zope.app.wsgi, we found that there were some idiosyncracies woven in that people may rely on. This kind of stuff of course isn't documented, and we didn't do much research, but rather took care to port what we found in zope.app.wsgi, namely filtering some HTTP headers from the response (meh, doesn't feel important), and handling Basic Auth headers (that feels important to preserve).
- What should happen in zope.app.wsgi?
We moved the wsgi-based Testbrowser from there and left BBB imports to zope.testbrowser.wsgi, taking care to be API compatible. I guess that won't be possible with the WebTest-based Testbrowser (or would it?), so we probably have to break that. (Hmm, would that imply a major version bump there, too?)
Since the Grok people are the ones who probably use the zope.app.wsgi Testbrowser the most, they should probably take the WebTest-Testbrowser for a test drive and see whether it works for them, otherwise we're going to make them quite unhappy if we just break zope.app.wsgi. (Could you ask on grok-dev about that? I guess it's too buried here to be noticed.)
- What's connection.py?
I don't really understand where that came from or what its purpose is, especially since wsgi.py seems to be the only one that uses it?
Ah. I take that last bit back, the extracted Publisher-Browser in zope.app.testing uses it, so I guess this is a split-off artifact of the refactoring/extraction.
But I still don't really understand what it is all about. %-)
- The layer looks good. (OK, so that's not a question ;)
I'm glad you found a way that the browser can get the application "out of the air". I've tried the explicit passing way on a project of mine, and it's a huge hassle (I've ended up stuffing a preconfigured browser instance into the doctest globs, ugh.)
I think it would be good if the layer stored the application of self.app, we did that in the wsgi_intercept variant and were glad of it a few times already.
b) extract the testbrowser part that talks to the Publisher
This is here and by necessity includes the changes for step (a): svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser
The extraction of the Publisher-Browser makes a lot of sense, and looks clean to me, as does the rewrite of the tests to use a plain WSGI app instead of a Zope-based app.
I would much prefer to merge both steps together.
Yes, I guess that makes sense because only step (b) includes proper tests for everything.
Wolfgang
_______________________________________________ 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 )
-- Brian Sutherland
On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote:
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it
Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week.
Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself)
I can give you PyPI access to all three. Note: when asking for PyPI access it's customary to mention one's PyPI username. Marius Gedminas -- Look! Before our very eyes, the future is becoming the past.
On Thu, Mar 10, 2011 at 11:07 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote:
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it
Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week.
Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself)
I can give you PyPI access to all three.
Note: when asking for PyPI access it's customary to mention one's PyPI username.
I guessed his user name as 'jinty' and added, is that correct ? Regards, Baiju M
On Thu, Mar 10, 2011 at 07:07:24PM +0200, Marius Gedminas wrote:
On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote:
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it
Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week.
Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself)
I can give you PyPI access to all three.
Great!
Note: when asking for PyPI access it's customary to mention one's PyPI username.
I hadn't used it for such a long time I even had to look it up: jinty -- Brian Sutherland
On 10 March 2011 18:18, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 10, 2011 at 07:07:24PM +0200, Marius Gedminas wrote:
On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote:
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it
Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week.
Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself)
I can give you PyPI access to all three.
Great!
Note: when asking for PyPI access it's customary to mention one's PyPI username.
I hadn't used it for such a long time I even had to look it up: jinty
-- Brian Sutherland _______________________________________________ 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 )
Just released zope.app.wsgi 3.13 that picks up the changes in zope.testbrowser 4.0, also updated ZTK trunk. -- Jan-Jaap Driessen
On Wed, Mar 16, 2011 at 12:08:12AM +0100, Jan-Jaap Driessen wrote:
On 10 March 2011 18:18, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 10, 2011 at 07:07:24PM +0200, Marius Gedminas wrote:
On Thu, Mar 10, 2011 at 04:22:25PM +0100, Brian Sutherland wrote:
I now believe I've taken care of all the issues raised in your review. connection.py still feels uncomfortable, but I can live with it
Unless there are any objections, I plan to merge all three branches (zope.testbrowser, zope.app.wsgi and zope.app.testing) early next week.
Is there anyone willing to make releases of these to PyPI? (or give me the access to do it myself)
I can give you PyPI access to all three.
Great!
Note: when asking for PyPI access it's customary to mention one's PyPI username.
I hadn't used it for such a long time I even had to look it up: jinty
-- Brian Sutherland _______________________________________________ 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 )
Just released zope.app.wsgi 3.13 that picks up the changes in zope.testbrowser 4.0, also updated ZTK trunk.
Great, it looks like we're done. Aside from keeping an eye on the buildbots, of course. Thanks for all the help! -- Brian Sutherland
participants (9)
-
Baiju M -
Benji York -
Brian Sutherland -
Jan-Jaap Driessen -
Marius Gedminas -
Stephan Richter -
Sylvain Viollon -
Wichert Akkerman -
Wolfgang Schnerring