On Jan 21, 2008 10:30 PM, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > > the TurboGears 1 Team will concentrate on preparing a beta > > > release of the 1.1 branch and only critical bug-fixes will still be > > It's a good time to discuss about change the cherrypy version from 2 to > > 3. > > I know that the first try was done some time ago and developers have > > decided to stop migration, but, looking for cherrypy 3 features, maybe > > the benefits pay the work. > > If people are willing to help, we're willing to try to make this > happen in 1.1. I think the key things are 1) test infrastructure > updates and 2) updating the Turbogears configuraiton system to break > it out of cherrypy. > > I think there are plans already to work on issue 2, and if somebody is > willing to integrate paste.fixture style testing into TG 1.1, that > will be a benifit as people move their apps from 1.1 to 2.0.
(Moving this conversation to the trunk list) I've made a couple of attempts of working with the CP3 branch. I'd like to share some of the lessons/mistakes I've made along the way.. hopefully someone will find value in them. Starting with #2, the config system, it doesn't seem too difficult to hack together support for the new CP3 approach [1]. I posted something similar a while back, but Florent was working on a more complete re-write, so I didn't push the issue. My hack seems to work, though, so maybe it's worth mentioning again. Regarding #1, the test infrastructure, I've tried a couple of approaches. First, I tried creating a "Fixture Like" class that wrapped cherrypy's response object to produce something that looked vaguely like paste.fixture. At the time, it seemed like making this complete was more work than I had time for, so I then switched to twill, adding a feature to grab the wsgi environment when using wsgi_intercept (as a stand-in for testutil.call & call_with_request). I had some success with this approach [2], but I ended up creating a big performance problem (~2 seconds per test) & somehow broke nose in the process. I now view the attempt of moving to twill as too aggressive & a distraction -- there's enough already changing that we shouldn't add more needlessly. So, I'm ready to switch back to doing something fixture-based, except for one question: now that TG2 is using webob, does it follow that it will soon switch to using webtest? If so, we should use/mimic that API instead. The other question that comes up is how to get people to start doing something besides importing cherrpy & using it's response object in their tests. It seems to me that create_request should return a webob-like response that should be used [3]. Should testutil monkey-patch cherrypy.response to issue a deprecation warning to let people know they should be switching over? In the push towards tg 2.0, eventually something should also be done in the tests to abstract away mounting apps via assigning cherrpy.root, but that's another ball of wax. Anyway, I hope some of this makes sense.. it's late. -ken [1] http://paste.turbogears.org/paste/1913 [2] I had about 1/2 the cp3 branch's unit tests running successfully, and just 12 failures against the 1.0 branch (and it works great for my own project.) [3] testutil.call would return a tg specific portion of the wsgi env. controllers.py would need to be modified to add stuff to the wsgi env. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
