Unwinding the Twisted Web (a progress report)
I had been trying to straighten out the model for the split since my first post to twisted-web regarding it. Now that radix, and exarkun have split twisted.news out of the core codebase as "lowdown". Since then I have begun work on my own source tree of twisted.web, the module has been split as "unwound" which is my proposed name as mentioned in the numerous naming threads (to be installed as tmlabs.unwound if desired.) So far I've done the following: * duplicate the source tree renaming the toplevel module and changing the imports accordingly. * run the tests (everything passes just as it does in twisted.web) * removed modules that were deprecated BY woven, and added a Deprecation Warning message to unwound.woven.__init__ If there are no complaints about this I'm asking someone (like radix) to help me complete the rest of the steps necessary to make this the official split so i can start working on changes and enhancements. The things I can't do on my own, atleast not as part of twistedmatrix.com is setup the SVN repo and the project page. Also it appears if radix and exarkun did not solve (or atleast did not implmenet a solution for) the tap naming conflicts. I.E. if lowdown or tmlabs.lowdown is going to use mktap news or mktap lowdown instead. Other than that, Unwound is currently a useable tree of twisted.web At revision 10601. (I'm open to changing the name to either tmlabs.web or some cute/catchy name other than 'unwound', but ultimately I think that is a policy decision that falls on the core twisted devs.) -- David Reid Claim to fame: "I actually wrote code that used twisted.web.webwidgets!"
David Reid wrote:
I had been trying to straighten out the model for the split since my first post to twisted-web regarding it. Now that radix, and exarkun have split twisted.news out of the core codebase as "lowdown".
Sorry, but we've changed that again. :-) It's now (going to be) 'tmlabs.news', and the project name will probably remain "Twisted News". (This is why we split news first, so we could go back and forth without anybody caring about the project we're jerking around. :)
Since then I have begun work on my own source tree of twisted.web, the module has been split as "unwound" which is my proposed name as mentioned in the numerous naming threads (to be installed as tmlabs.unwound if desired.)
If there are no complaints about this I'm asking someone (like radix) to help me complete the rest of the steps necessary to make this the official split so i can start working on changes and enhancements. The things I can't do on my own, atleast not as part of twistedmatrix.com is setup the SVN repo and the project page.
I'm kind of apprehensive about doing this split so suddenly, as we haven't figured out the process of doing the split with other less important packages. e.g., we don't even have a working tmlabs.news package yet. Also, I would like to *close* the issue of naming first (see below for my opinion). We didn't do that before doing the twisted.news split, and we had to do a bunch of extra unnecessary work because of it.
Also it appears if radix and exarkun did not solve (or atleast did not implmenet a solution for) the tap naming conflicts. I.E. if lowdown or tmlabs.lowdown is going to use mktap news or mktap lowdown instead.
Actually, we did. The solution is to REMOVE the tap from Twisted proper. In fact, we removed *all* news/nntp code from Twisted proper, and just put in compatibility modules that imported stuff from lowdown (soon to be changed to tmlabs.news). So there is backwards compatibility for SOURCE, but you need to install the new package if you want it. That new package provides the (only) tapper.
Other than that, Unwound is currently a useable tree of twisted.web At revision 10601.
(I'm open to changing the name to either tmlabs.web or some cute/catchy name other than 'unwound', but ultimately I think that is a policy decision that falls on the core twisted devs.)
Indeed, I think we should stick with the current names, with only a s/twisted/tmlabs/ change. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
So a few things: - I think we should dump woven. - What is our compatibility story with old twisted-web? Now is a good time to make a break, so I think it should be done. By that I mean, new-twisted-web would not guarantee 100% backwards compatibleness with the old API. If you want 100% old API, use the old code. Wrappers *should* be provided for some normally called methods on Resource/Request such that much of people's old code will work, if it's doing normal resourcish stuff and not trying to be tricksy. - So, should a final release of OldTwistedWeb be done so people can keep updating to newer versions of twisted core and leave old twisted web alone? James
On Thu, 2004-04-22 at 15:09, James Y Knight wrote:
So a few things: - I think we should dump woven. - What is our compatibility story with old twisted-web? Now is a good time to make a break, so I think it should be done. By that I mean, new-twisted-web would not guarantee 100% backwards compatibleness with the old API. If you want 100% old API, use the old code. Wrappers *should* be provided for some normally called methods on Resource/Request such that much of people's old code will work, if it's doing normal resourcish stuff and not trying to be tricksy. - So, should a final release of OldTwistedWeb be done so people can keep updating to newer versions of twisted core and leave old twisted web alone?
James
If so the work of splitting out a working codebase for oldweb has been done, a rename should be rendered trivial by a quick sed script. -- David
James Y Knight wrote:
So a few things: - I think we should dump woven.
We never deprecated it :-(
- What is our compatibility story with old twisted-web? Now is a good time to make a break, so I think it should be done. By that I mean, new-twisted-web would not guarantee 100% backwards compatibleness with the old API. If you want 100% old API, use the old code. Wrappers *should* be provided for some normally called methods on Resource/Request such that much of people's old code will work, if it's doing normal resourcish stuff and not trying to be tricksy. - So, should a final release of OldTwistedWeb be done so people can keep updating to newer versions of twisted core and leave old twisted web alone?
I think we should just put all backwards-compatibility code into twisted.web. So twisted.web will be API-compatible, and all of our BC code will live in Twisted. It will still require tmlabs.web (or whatever), and just wrap its APIs. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Apr 22, 2004, at 7:27 PM, Christopher Armstrong wrote:
I think we should just put all backwards-compatibility code into twisted.web. So twisted.web will be API-compatible, and all of our BC code will live in Twisted. It will still require tmlabs.web (or whatever), and just wrap its APIs.
Lofty goal -- but I'm not sure it's actually possible. See current state of Nevow compatibility. It's somewhat backwards compatible, and works for "normal" resources, but has certain things that don't quite work together due to new resource API. Do you think that's fixable? I have not spent a great amount of time looking for a solution so there may be one but I didn't see an easy fix. Or do you mean backwards compatible in that you could the old API, but it won't necessarily work if you use it with the new API in the same app? Perhaps just that twisted.web.* has been reimplemented such that its internals are now written in terms of tmlabs.web but it's otherwise a separate world? If so, I'm not sure that's actually worth much. James
On Fri, 2004-04-23 at 11:46, James Y Knight wrote:
On Apr 22, 2004, at 7:27 PM, Christopher Armstrong wrote:
I think we should just put all backwards-compatibility code into twisted.web. So twisted.web will be API-compatible, and all of our BC code will live in Twisted. It will still require tmlabs.web (or whatever), and just wrap its APIs.
Lofty goal -- but I'm not sure it's actually possible. See current state of Nevow compatibility.
I think what we need is a situation where applications written entirely with twisted.web.*, and no Nevow whatsoever, still function properly. Breaking backwards-compatibility for all those users would be a big mistake. I believe this is what Chris has been talking about -- right? If we can't maintain that backwards-compatibility through wrapper APIs, then we should leave the old twisted.web in the Twisted package for at least one or two release cycles, pepper it with DeprecationWarnings, and do our best to tell users to either spend the minimal effort porting their app to tmlabs.web, or to keep using old versions of Twisted. -- Alex Levy WWW: http://mesozoic.geecs.org/ "Never let your sense of morals prevent you from doing what is right." -- Salvor Hardin, Isaac Asimov's _Foundation_
participants (4)
-
Alex Levy -
Christopher Armstrong -
David Reid -
James Y Knight