[Twisted-Python] Fwd: [Twisted-commits] r11721 - revert r11685
Why is this unacceptable? We depend on pyOpenSSL for TLS support, etc..
On Sun, 19 Sep 2004 10:07:57 -0400, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
Why is this unacceptable? We depend on pyOpenSSL for TLS support, etc..
The logistical reasons: There is no release of Nevow. None of the buildslaves have even an SVN trunk checkout installed, nor have any of them been asked to install one. Developers weren't told about this new dependency, so they may not have it installed. This leads to strangely failing tests, making it difficult to tell if outstanding changes that a developer wants to commit are broken. The technical reasons: Nevow imports Twisted. Therefore, Twisted should not import Nevow. Twisted is the networking framework and the web server framework. It is lower level than the application server and the templating system. The latter should depend on the former, if a dependency exists, not the reverse. _If_ it is desired for Twisted to gain functionality from a Nevow installed, Nevow must be careful to only import certain things from Twisted. I would much prefer if Nevow gained functionality from Twisted and not the reverse, but if twisted.web/nevow developers desire things to work as they do currently in twisted.web2, at least the above issues need to be addressed. This thread should serve to resolve one of them (hopefully Twisted developers are now aware of the potential dependency ;). Jp
On Sep 19, 2004, at 12:30 PM, <exarkun@divmod.com> wrote:
First off -- I consider this a rude thing to do, considering I am far from being unreachable. What was the emergency that prompted this removal at midnight on a saturday night? None? Yeah, that's what I thought.
There is. Although it's old. This is a very good reason for not releasing twisted.web2. Fortunately, since we have decoupled releases now, it doesn't affect anything else.
None of the buildslaves have even an SVN trunk checkout installed, nor have any of them been asked to install one.
True.
Developers weren't told about this new dependency, so they may not have it installed.
twisted-web ml was. I don't expect developers that don't care about twisted web to install Nevow.
This leads to strangely failing tests, making it difficult to tell if outstanding changes that a developer wants to commit are broken.
I assume you mean "Could not import twisted.web2.test.test_web: Traceback: exceptions.ImportError, No module named nevow.". If so, "strangely failing tests" is quite a hyperbole.
Most of Twisted web2 does not/will not depend on Nevow. Generation of some server-generated pages does/will. Those tests should just be skipped if Nevow isn't installed. That they aren't is an issue, sure. If you want to have any input on these technical matters I suggest participating on the twisted-web mailing list instead of just randomly removing code. Please re-add it. James
On Sun, 19 Sep 2004 20:19:42 -0400, James Y Knight <foom@fuhm.net> wrote:
I'm sorry you took it this way. I assure you I had nothing in mind but the best interest of Twisted at the time. I appreciate all the work you've done on the web rewrite. As to the "emergency" which prompted the removal: I was trying to commit a patch to twisted.mail; various problems led to this taking several hours. Several of these problems had nothing to do with web2, but the failing web2 tests were a contributing factor. I did not come up with the idea to revert the web2 commit on the spot. Commits which introduce broken tests have always been fair game for reversion. Since the web2 tests were _new_, perhaps a different policy might apply. I'd certainly be willing to entertain arguments to that effect to decide what should be done in the future. I do not think reverting the commit was unreasonable here, though.
Perhaps I should have added "that which make this code work." Decoupled releases are good, yes. That solves one problem with checking broken tests (the tests may pass with nevow installed, I still haven't tried, that doesn't mean they aren't broken though). There are others.
So before we re-add twisted.web2, let's see what we can do about fixing this situation.
If the tests were skipped when nevow was not installed, this would be reasonable. Since they're not, developers who don't care about twisted web are forced to care about it.
Okay, let's get that fixed as well, then I will gladly re-add web2 for you. If you like, I will also merge the minor fixes that were made to trunk into the web2 branch, so that those are not lost.
I am happy with my current level of avoidance of twisted web, discounting this most recent event. I hope that in the future web2 can be handled in such a way that it is not disruptive to those of us who are not interested in it. Jp
On Sun, 2004-09-19 at 22:35, exarkun@divmod.com wrote:
No, I don't think that a different policy should apply - revision history exists for a reason. This point is worth emphasizing. We don't have a very rigorous process in place for development, but this has always been the case - trunk should be in a working state at all times. If you check in code that breaks the tests, it is at the discretion of any other developer to decide that your code is toast: it doesn't matter if you are available on IRC in real time. You can fix your breakages locally, without everyone else waiting for you.
The first release of Twisted 2.0 will not be decoupled. It is important that we don't treat the releases as decoupled until we have actually successfully made at least one decoupled release of each project. I don't think this policy will change when project release cycles are separated though. Even when trunk is in a completely working state, it is still difficult to get a release done right now, so I see no reason to accept tests which do not import, or tests which fail, in trunk. If you want to add a dependency on something new, this needs to be discussed before checking in.
Do those server-side pages have simple, non-nevow fallbacks? If they can't, then perhaps we should be considering a merged release.
Personally I believe this is worth discussing generally, because these are not "web development" issues, although they do touch web code - I don't subscribe to twisted-web because I'm not interested in the particulars of HTTP rfc compliance or url argument parsing, but I most certainly *am* interested in circular dependencies threading through libraries which are distributed separately. There is perhaps a larger discussion here about the relationship between twisted-web and nevow, and Twisted and Divmod in general, that needs to happen on divmod-dev.
Maybe I need to be a little more involved than I have been. I find the presence of both web and web2 in the same source tree a little upsetting - this harkens back the web.widgets / web.domtemplate / web.woven API disaster, which still haunts us. Let's try to figure out which web server we are supporting and then actually support it, rather than having 9 different half-assed, half-supported implementations floating around.
On Sep 20, 2004, at 12:40 AM, Glyph Lefkowitz wrote:
Well, certainly nobody who wrote the original twisted.web code is supporting it, but that doesn't mean it's unusable. On the contrary, it's very usable, and there are probably lots and lots of applications which depend on all sorts of subtle and broken semantics it uses (people being far more interested in developing web related things than finger related things). I don't see any sane way to perform a complete rewrite with better semantics while still living in the old twisted.web namespace, especially given the miniscule amount of time most of the major developers of this project have to put against it. Developing backwards compatibility with the old APIs would be a death march, would never quite work anyway, and wouldn't really benefit anyone in particular. We already figured out which web server we ("we" being those developers who actually care about the web) are going to be supporting. twisted.web2. web should have a deprecation warning in __init__ for a release, and then should be terminated with extreme prejudice. As far as the nevow dependency, I have already suggested to James that twisted.web2 should work without it, but he didn't feel it was worth the effort. If it is worth the effort to someone else, I suggest they do it. My suggestion is simply not to have pages like directory listings and traceback renderings, but to have simple string templates which are returned in the case of nevow not being installed. This way you can use web2 with no dependencies to do a completely custom web server, but you're not going to get much out of the box. dp
On Mon, 2004-09-20 at 10:07, Donovan Preston wrote:
The twisted 1.3 release will available for download for the forseeable future, for those who need it. I don't believe we should release stuff with subtle, broken semantics in twisted 2.0 - the release number implies that we are changing a few things, so this would be a good opportunity to abandon support for the old code.
If there is to be no backwards compatibility, why bother with the separate namespace? Do we want to do this with other modules in the future, e.g. twisted.spread2? Our last discussion of this was inconclusive because I don't think we foresaw the web rewrite being so radically different. I guess we have to drag that dead horse out here to beat it one more time ;). Even if the namespace changes, there should only be one of these in svn at a time. If further development on twisted web 1 is going to continue it should be in a maintenance branch, and then we need to discuss how we're going to manage maintenance releases.
I would terminate before providing a deprecation warning. If you want to provide a backwards-compatibility release for using web1 with the new reactor core, that's fine, but I don't see any reason to include web1 with the new download.
As far as the nevow dependency, [...] you're not going to get much out of the box.
It really sounds like nevow and web2 ought to be merged. Traffic on the twisted-web list suggests that anyone who is using one is using the other, at least in some capacity. The marketing aspect of this certainly requires some discussion, but it seems that one's utility is greatly reduced without the other, and the dependency is circular. For specialized cases, such as using nevow for CGI scripts, there is no problem with having the other code around as long as it can avoid being imported.
On Mon, 2004-09-20 at 10:49, Glyph Lefkowitz wrote:
twisted.web will not be included. There will be two downloads ("Twisted Web 1 - Deprecated", "Twisted Web 2"). Most people will not download the first ever. The first will likely not have new releases unless we fine security issues. Moving it to branch and only doing releases from there may be fine (if our release infrastructure is up to it!) but I still think newweb should be twisted.web2. Summary: 1. twisted.web2 remains web2. 2. Move twisted.web (and any other security bugfix only packages, I guess) to a "deprecated" branch. Yes? No? If yes, that just leaves the nevow/twisted.web2 merger question, which should probably be done on twisted-web mailing list.
On Mon, 20 Sep 2004 11:08:46 -0400, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
Don't bother moving twisted.web to a branch; the repository layout of trunk is (will be) decoupled from how releases are done, and since both will potentially be changed (e.g. for security) then I don't think it should be in a separate branch. And +1 on keeping the name twisted.web2. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com
OK, final summary: 1. twisted.web2 stays as named and in trunk. 2. twisted.web stays as named and in trunk. 3. Both get releases post-2.0 split up (but after that twisted.web only gets security fix releases). Nevow is separate issue, to be discussed on twisted-web, but note that stuff in twisted trunk really ought to have passing tests.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Urgh. I usually avoid getting involved in these discussions--not because I don't want to participate but because the ML style does not work very well with my brain. There's all these different parts of this proposal and some are being rejected by some people and modified by other people and it's very hard for me to figure out what the whole picture is. In this case, I have to say something because this is pretty important to the product I'm developing. I just spent 6 weeks doing a conversion to Nevow because Woven isn't being supported any more. I do *not* want to do the same thing with Web. I've made modifications to Twisted trunk that I was hoping to get out of 2.0 for our official release, but if there's not going to be a web1 any more, that puts this project in jeopardy again because it means I may not be able to use 2.0. So here's what I have to say: please *summarize*. I need to get a sense of: 1) Timeline.. when are changes being implemented, in what order, tied to what release etc. 2) How is the svn repo going to change? 3) What is going to be put into what release by whom? 4) What's the impact if you're currently using web1 and you want to be using web2 because 1 isn't supported any more? 5) What's the impact if you stay with web1? If you haven't decided yet, go ahead and decide, but then summarize afterwards. :-) Thanks.. C Itamar Shtull-Trauring wrote: | On Mon, 2004-09-20 at 10:49, Glyph Lefkowitz wrote: | | |>>We already figured out which web server we ("we" being those developers |>>who actually care about the web) are going to be supporting. |>>twisted.web2. web should have a deprecation warning in __init__ for a |>>release, and then should be terminated with extreme prejudice. |> |>I would terminate before providing a deprecation warning. If you want |>to provide a backwards-compatibility release for using web1 with the new |>reactor core, that's fine, but I don't see any reason to include web1 |>with the new download. | | | twisted.web will not be included. There will be two downloads ("Twisted | Web 1 - Deprecated", "Twisted Web 2"). Most people will not download the | first ever. The first will likely not have new releases unless we fine | security issues. Moving it to branch and only doing releases from there | may be fine (if our release infrastructure is up to it!) but I still | think newweb should be twisted.web2. | | | Summary: | | 1. twisted.web2 remains web2. | 2. Move twisted.web (and any other security bugfix only packages, I | guess) to a "deprecated" branch. | | Yes? No? | | If yes, that just leaves the nevow/twisted.web2 merger question, which | should probably be done on twisted-web mailing list. | | | | _______________________________________________ | Twisted-Python mailing list | Twisted-Python@twistedmatrix.com | http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBTvtx3A5SrXAiHQcRApINAKCggxacS+kFLmAszBQmrQeuByJHBgCgnyov jBEWFaH7dZ6TZBbtljvVZTg= =tLpe -----END PGP SIGNATURE-----
I guess I'll keep the crossposting, since this may be of interest to those who do not read the twisted-web list. On Sep 20, 2004, at 11:46 AM, Cory Dodt wrote:
I do not want that to happen. Note foremost what web2 is. 1) A rewrite of the Request/low level HTTP layer. 2) *Migrating* the Nevow resource model back into the core webserver where it belongs. Where there are conflicting statements by others, I'd go with what I say since so far I seem to be in charge of web2. ;) In quick summary: since you've already migrated to Nevow, I expect to be able to provide easy compatibility with your app so you can use new releases of Nevow that depend on web2 with little work. If you currently have web1 resources working with Nevow, they will also work with Nevow/web2.
Web2 will be done when it is done, hopefully by the time Twisted 2.0 releases, but if not, then not. In parallel with development of web2, a branch of the Nevow repository will be developed that uses t.web2. That should be released at the same time. Web1 will stay around for the indefinite future. SVN trunk of Nevow will remain dependent only upon web1 until such a time as web2&nevow-which-uses-it work sufficiently well at which point that branch will merge with the trunk.
2) How is the svn repo going to change?
Right now? t.web2 gets added to Twisted. Nevow gets a branch.
3) What is going to be put into what release by whom?
I don't know what you're asking.
The migration from web1 to web2 will be about the same difficulty as the migration from web1 to Nevow. However, you are currently not using (most of) web1, so that is the wrong question to ask. You are using Nevow's appserver, which is basically the same as what web2's appserver will be. Web2 will be mostly compatible with current Nevow. I say mostly only because it may not be feasible to provide absolutely complete compatibility, but I'd like to provide compatibility for all the things that normal apps use (Nevow Resource API and app-facing parts of the Request object). Web2 will be somewhat compatible with web1 Resources. "Somewhat" here means basically the same thing it already means with Nevow (since the code will be essentially the same code). If you're using the Nevow "appserver" now, ideally you will not have to change your app for it to work with web2, although you may want to change some things to avoid deprecation warnings. Not everything always turns out ideally, so I can't promise that, but it is the goal.
5) What's the impact if you stay with web1?
You cannot use new releases of Nevow after <whenever web2 is done and the Nevow branch is merged>. Web1 will continue to have the same amount of maintenance as it does now (namely: almost none) James
On Mon, 2004-09-20 at 13:16, James Y Knight wrote:
I guess I'll keep the crossposting, since this may be of interest to those who do not read the twisted-web list.
Thanks james, that was a great summary of just about every web issue that I am concerned with. And thanks for the questions, MFen... Unless anybody else objects I think this thread should be the last of the crossposting :)
On Mon, 2004-09-20 at 11:08, Itamar Shtull-Trauring wrote:
OK. I am going to re-propose my way of versioning interfaces since this is a subset of it, but in the interests of not holding this up, this is fine :).
2. Move twisted.web (and any other security bugfix only packages, I guess) to a "deprecated" branch.
Thinking about this a little more: +0 My main concern was that there was going to be a single download. Upon further reflection, we are probably going to need some good policy for how to do this - branching from all of trunk is bad since you don't want to capture other buggy code along with it... I'd like to see some way that we can clearly mark deprecated modules in trunk though, for new developers.
Yes? No?
Sounds fine to me, as long as no other package maintainers have a problem with tacking on a version number to the end of their package names when they make large API changes. I forsee we are going to have a lot of those :).
If yes, that just leaves the nevow/twisted.web2 merger question, which should probably be done on twisted-web mailing list.
I can get divmod to provide a conference line if this would benefit from a real-time discussion, which I think it might.
James Y Knight wrote:
I have something that Works For Me. It makes sense to me (from an API point of view), and, more importantly for my current use-cases, works with urllib's Request objects, which means you can drop ClientForm on top of it directly, and it Just Works. This is good. It also works on top of a UDP transport, which the current http client does not. While HTTP-over-UDP is an Abomination In The Eyes of Great Cthulu, it's also used in some sick and warped protocols, which I need to support. Anthony
A snapshot of the stuff I have working is at: http://www.interlink.com.au/anthony/tmp/nonsuckhttp.py I'm not sure if this is the absolute latest version - will check tomorrow morning after sleeps. Anthony
On Sun, 2004-09-19 at 12:30, exarkun@divmod.com wrote:
Nevow imports Twisted. Therefore, Twisted should not import Nevow.
Incorrect. If nevow imports twisted.internet and twisted.web2 imports nevow that is fine since it is a different project. I think having twisted,web2 at least be semi-functional without nevow (i.e. importable and tests running) would be good enough for your concerns?
On Sun, 19 Sep 2004 22:02:35 -0400, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
If twisted.web2 provided a reduced level of functionality in the absence of nevow, that'd be fine. Good enough for me will be having the web2 tests skipped when its dependencies are not installed. Jp
Why is this unacceptable? We depend on pyOpenSSL for TLS support, etc..
On Sun, 19 Sep 2004 10:07:57 -0400, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
Why is this unacceptable? We depend on pyOpenSSL for TLS support, etc..
The logistical reasons: There is no release of Nevow. None of the buildslaves have even an SVN trunk checkout installed, nor have any of them been asked to install one. Developers weren't told about this new dependency, so they may not have it installed. This leads to strangely failing tests, making it difficult to tell if outstanding changes that a developer wants to commit are broken. The technical reasons: Nevow imports Twisted. Therefore, Twisted should not import Nevow. Twisted is the networking framework and the web server framework. It is lower level than the application server and the templating system. The latter should depend on the former, if a dependency exists, not the reverse. _If_ it is desired for Twisted to gain functionality from a Nevow installed, Nevow must be careful to only import certain things from Twisted. I would much prefer if Nevow gained functionality from Twisted and not the reverse, but if twisted.web/nevow developers desire things to work as they do currently in twisted.web2, at least the above issues need to be addressed. This thread should serve to resolve one of them (hopefully Twisted developers are now aware of the potential dependency ;). Jp
On Sep 19, 2004, at 12:30 PM, <exarkun@divmod.com> wrote:
First off -- I consider this a rude thing to do, considering I am far from being unreachable. What was the emergency that prompted this removal at midnight on a saturday night? None? Yeah, that's what I thought.
There is. Although it's old. This is a very good reason for not releasing twisted.web2. Fortunately, since we have decoupled releases now, it doesn't affect anything else.
None of the buildslaves have even an SVN trunk checkout installed, nor have any of them been asked to install one.
True.
Developers weren't told about this new dependency, so they may not have it installed.
twisted-web ml was. I don't expect developers that don't care about twisted web to install Nevow.
This leads to strangely failing tests, making it difficult to tell if outstanding changes that a developer wants to commit are broken.
I assume you mean "Could not import twisted.web2.test.test_web: Traceback: exceptions.ImportError, No module named nevow.". If so, "strangely failing tests" is quite a hyperbole.
Most of Twisted web2 does not/will not depend on Nevow. Generation of some server-generated pages does/will. Those tests should just be skipped if Nevow isn't installed. That they aren't is an issue, sure. If you want to have any input on these technical matters I suggest participating on the twisted-web mailing list instead of just randomly removing code. Please re-add it. James
On Sun, 19 Sep 2004 20:19:42 -0400, James Y Knight <foom@fuhm.net> wrote:
I'm sorry you took it this way. I assure you I had nothing in mind but the best interest of Twisted at the time. I appreciate all the work you've done on the web rewrite. As to the "emergency" which prompted the removal: I was trying to commit a patch to twisted.mail; various problems led to this taking several hours. Several of these problems had nothing to do with web2, but the failing web2 tests were a contributing factor. I did not come up with the idea to revert the web2 commit on the spot. Commits which introduce broken tests have always been fair game for reversion. Since the web2 tests were _new_, perhaps a different policy might apply. I'd certainly be willing to entertain arguments to that effect to decide what should be done in the future. I do not think reverting the commit was unreasonable here, though.
Perhaps I should have added "that which make this code work." Decoupled releases are good, yes. That solves one problem with checking broken tests (the tests may pass with nevow installed, I still haven't tried, that doesn't mean they aren't broken though). There are others.
So before we re-add twisted.web2, let's see what we can do about fixing this situation.
If the tests were skipped when nevow was not installed, this would be reasonable. Since they're not, developers who don't care about twisted web are forced to care about it.
Okay, let's get that fixed as well, then I will gladly re-add web2 for you. If you like, I will also merge the minor fixes that were made to trunk into the web2 branch, so that those are not lost.
I am happy with my current level of avoidance of twisted web, discounting this most recent event. I hope that in the future web2 can be handled in such a way that it is not disruptive to those of us who are not interested in it. Jp
On Sun, 2004-09-19 at 22:35, exarkun@divmod.com wrote:
No, I don't think that a different policy should apply - revision history exists for a reason. This point is worth emphasizing. We don't have a very rigorous process in place for development, but this has always been the case - trunk should be in a working state at all times. If you check in code that breaks the tests, it is at the discretion of any other developer to decide that your code is toast: it doesn't matter if you are available on IRC in real time. You can fix your breakages locally, without everyone else waiting for you.
The first release of Twisted 2.0 will not be decoupled. It is important that we don't treat the releases as decoupled until we have actually successfully made at least one decoupled release of each project. I don't think this policy will change when project release cycles are separated though. Even when trunk is in a completely working state, it is still difficult to get a release done right now, so I see no reason to accept tests which do not import, or tests which fail, in trunk. If you want to add a dependency on something new, this needs to be discussed before checking in.
Do those server-side pages have simple, non-nevow fallbacks? If they can't, then perhaps we should be considering a merged release.
Personally I believe this is worth discussing generally, because these are not "web development" issues, although they do touch web code - I don't subscribe to twisted-web because I'm not interested in the particulars of HTTP rfc compliance or url argument parsing, but I most certainly *am* interested in circular dependencies threading through libraries which are distributed separately. There is perhaps a larger discussion here about the relationship between twisted-web and nevow, and Twisted and Divmod in general, that needs to happen on divmod-dev.
Maybe I need to be a little more involved than I have been. I find the presence of both web and web2 in the same source tree a little upsetting - this harkens back the web.widgets / web.domtemplate / web.woven API disaster, which still haunts us. Let's try to figure out which web server we are supporting and then actually support it, rather than having 9 different half-assed, half-supported implementations floating around.
On Sep 20, 2004, at 12:40 AM, Glyph Lefkowitz wrote:
Well, certainly nobody who wrote the original twisted.web code is supporting it, but that doesn't mean it's unusable. On the contrary, it's very usable, and there are probably lots and lots of applications which depend on all sorts of subtle and broken semantics it uses (people being far more interested in developing web related things than finger related things). I don't see any sane way to perform a complete rewrite with better semantics while still living in the old twisted.web namespace, especially given the miniscule amount of time most of the major developers of this project have to put against it. Developing backwards compatibility with the old APIs would be a death march, would never quite work anyway, and wouldn't really benefit anyone in particular. We already figured out which web server we ("we" being those developers who actually care about the web) are going to be supporting. twisted.web2. web should have a deprecation warning in __init__ for a release, and then should be terminated with extreme prejudice. As far as the nevow dependency, I have already suggested to James that twisted.web2 should work without it, but he didn't feel it was worth the effort. If it is worth the effort to someone else, I suggest they do it. My suggestion is simply not to have pages like directory listings and traceback renderings, but to have simple string templates which are returned in the case of nevow not being installed. This way you can use web2 with no dependencies to do a completely custom web server, but you're not going to get much out of the box. dp
On Mon, 2004-09-20 at 10:07, Donovan Preston wrote:
The twisted 1.3 release will available for download for the forseeable future, for those who need it. I don't believe we should release stuff with subtle, broken semantics in twisted 2.0 - the release number implies that we are changing a few things, so this would be a good opportunity to abandon support for the old code.
If there is to be no backwards compatibility, why bother with the separate namespace? Do we want to do this with other modules in the future, e.g. twisted.spread2? Our last discussion of this was inconclusive because I don't think we foresaw the web rewrite being so radically different. I guess we have to drag that dead horse out here to beat it one more time ;). Even if the namespace changes, there should only be one of these in svn at a time. If further development on twisted web 1 is going to continue it should be in a maintenance branch, and then we need to discuss how we're going to manage maintenance releases.
I would terminate before providing a deprecation warning. If you want to provide a backwards-compatibility release for using web1 with the new reactor core, that's fine, but I don't see any reason to include web1 with the new download.
As far as the nevow dependency, [...] you're not going to get much out of the box.
It really sounds like nevow and web2 ought to be merged. Traffic on the twisted-web list suggests that anyone who is using one is using the other, at least in some capacity. The marketing aspect of this certainly requires some discussion, but it seems that one's utility is greatly reduced without the other, and the dependency is circular. For specialized cases, such as using nevow for CGI scripts, there is no problem with having the other code around as long as it can avoid being imported.
On Mon, 2004-09-20 at 10:49, Glyph Lefkowitz wrote:
twisted.web will not be included. There will be two downloads ("Twisted Web 1 - Deprecated", "Twisted Web 2"). Most people will not download the first ever. The first will likely not have new releases unless we fine security issues. Moving it to branch and only doing releases from there may be fine (if our release infrastructure is up to it!) but I still think newweb should be twisted.web2. Summary: 1. twisted.web2 remains web2. 2. Move twisted.web (and any other security bugfix only packages, I guess) to a "deprecated" branch. Yes? No? If yes, that just leaves the nevow/twisted.web2 merger question, which should probably be done on twisted-web mailing list.
On Mon, 20 Sep 2004 11:08:46 -0400, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
Don't bother moving twisted.web to a branch; the repository layout of trunk is (will be) decoupled from how releases are done, and since both will potentially be changed (e.g. for security) then I don't think it should be in a separate branch. And +1 on keeping the name twisted.web2. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com
OK, final summary: 1. twisted.web2 stays as named and in trunk. 2. twisted.web stays as named and in trunk. 3. Both get releases post-2.0 split up (but after that twisted.web only gets security fix releases). Nevow is separate issue, to be discussed on twisted-web, but note that stuff in twisted trunk really ought to have passing tests.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Urgh. I usually avoid getting involved in these discussions--not because I don't want to participate but because the ML style does not work very well with my brain. There's all these different parts of this proposal and some are being rejected by some people and modified by other people and it's very hard for me to figure out what the whole picture is. In this case, I have to say something because this is pretty important to the product I'm developing. I just spent 6 weeks doing a conversion to Nevow because Woven isn't being supported any more. I do *not* want to do the same thing with Web. I've made modifications to Twisted trunk that I was hoping to get out of 2.0 for our official release, but if there's not going to be a web1 any more, that puts this project in jeopardy again because it means I may not be able to use 2.0. So here's what I have to say: please *summarize*. I need to get a sense of: 1) Timeline.. when are changes being implemented, in what order, tied to what release etc. 2) How is the svn repo going to change? 3) What is going to be put into what release by whom? 4) What's the impact if you're currently using web1 and you want to be using web2 because 1 isn't supported any more? 5) What's the impact if you stay with web1? If you haven't decided yet, go ahead and decide, but then summarize afterwards. :-) Thanks.. C Itamar Shtull-Trauring wrote: | On Mon, 2004-09-20 at 10:49, Glyph Lefkowitz wrote: | | |>>We already figured out which web server we ("we" being those developers |>>who actually care about the web) are going to be supporting. |>>twisted.web2. web should have a deprecation warning in __init__ for a |>>release, and then should be terminated with extreme prejudice. |> |>I would terminate before providing a deprecation warning. If you want |>to provide a backwards-compatibility release for using web1 with the new |>reactor core, that's fine, but I don't see any reason to include web1 |>with the new download. | | | twisted.web will not be included. There will be two downloads ("Twisted | Web 1 - Deprecated", "Twisted Web 2"). Most people will not download the | first ever. The first will likely not have new releases unless we fine | security issues. Moving it to branch and only doing releases from there | may be fine (if our release infrastructure is up to it!) but I still | think newweb should be twisted.web2. | | | Summary: | | 1. twisted.web2 remains web2. | 2. Move twisted.web (and any other security bugfix only packages, I | guess) to a "deprecated" branch. | | Yes? No? | | If yes, that just leaves the nevow/twisted.web2 merger question, which | should probably be done on twisted-web mailing list. | | | | _______________________________________________ | Twisted-Python mailing list | Twisted-Python@twistedmatrix.com | http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBTvtx3A5SrXAiHQcRApINAKCggxacS+kFLmAszBQmrQeuByJHBgCgnyov jBEWFaH7dZ6TZBbtljvVZTg= =tLpe -----END PGP SIGNATURE-----
I guess I'll keep the crossposting, since this may be of interest to those who do not read the twisted-web list. On Sep 20, 2004, at 11:46 AM, Cory Dodt wrote:
I do not want that to happen. Note foremost what web2 is. 1) A rewrite of the Request/low level HTTP layer. 2) *Migrating* the Nevow resource model back into the core webserver where it belongs. Where there are conflicting statements by others, I'd go with what I say since so far I seem to be in charge of web2. ;) In quick summary: since you've already migrated to Nevow, I expect to be able to provide easy compatibility with your app so you can use new releases of Nevow that depend on web2 with little work. If you currently have web1 resources working with Nevow, they will also work with Nevow/web2.
Web2 will be done when it is done, hopefully by the time Twisted 2.0 releases, but if not, then not. In parallel with development of web2, a branch of the Nevow repository will be developed that uses t.web2. That should be released at the same time. Web1 will stay around for the indefinite future. SVN trunk of Nevow will remain dependent only upon web1 until such a time as web2&nevow-which-uses-it work sufficiently well at which point that branch will merge with the trunk.
2) How is the svn repo going to change?
Right now? t.web2 gets added to Twisted. Nevow gets a branch.
3) What is going to be put into what release by whom?
I don't know what you're asking.
The migration from web1 to web2 will be about the same difficulty as the migration from web1 to Nevow. However, you are currently not using (most of) web1, so that is the wrong question to ask. You are using Nevow's appserver, which is basically the same as what web2's appserver will be. Web2 will be mostly compatible with current Nevow. I say mostly only because it may not be feasible to provide absolutely complete compatibility, but I'd like to provide compatibility for all the things that normal apps use (Nevow Resource API and app-facing parts of the Request object). Web2 will be somewhat compatible with web1 Resources. "Somewhat" here means basically the same thing it already means with Nevow (since the code will be essentially the same code). If you're using the Nevow "appserver" now, ideally you will not have to change your app for it to work with web2, although you may want to change some things to avoid deprecation warnings. Not everything always turns out ideally, so I can't promise that, but it is the goal.
5) What's the impact if you stay with web1?
You cannot use new releases of Nevow after <whenever web2 is done and the Nevow branch is merged>. Web1 will continue to have the same amount of maintenance as it does now (namely: almost none) James
On Mon, 2004-09-20 at 13:16, James Y Knight wrote:
I guess I'll keep the crossposting, since this may be of interest to those who do not read the twisted-web list.
Thanks james, that was a great summary of just about every web issue that I am concerned with. And thanks for the questions, MFen... Unless anybody else objects I think this thread should be the last of the crossposting :)
On Mon, 2004-09-20 at 11:08, Itamar Shtull-Trauring wrote:
OK. I am going to re-propose my way of versioning interfaces since this is a subset of it, but in the interests of not holding this up, this is fine :).
2. Move twisted.web (and any other security bugfix only packages, I guess) to a "deprecated" branch.
Thinking about this a little more: +0 My main concern was that there was going to be a single download. Upon further reflection, we are probably going to need some good policy for how to do this - branching from all of trunk is bad since you don't want to capture other buggy code along with it... I'd like to see some way that we can clearly mark deprecated modules in trunk though, for new developers.
Yes? No?
Sounds fine to me, as long as no other package maintainers have a problem with tacking on a version number to the end of their package names when they make large API changes. I forsee we are going to have a lot of those :).
If yes, that just leaves the nevow/twisted.web2 merger question, which should probably be done on twisted-web mailing list.
I can get divmod to provide a conference line if this would benefit from a real-time discussion, which I think it might.
James Y Knight wrote:
I have something that Works For Me. It makes sense to me (from an API point of view), and, more importantly for my current use-cases, works with urllib's Request objects, which means you can drop ClientForm on top of it directly, and it Just Works. This is good. It also works on top of a UDP transport, which the current http client does not. While HTTP-over-UDP is an Abomination In The Eyes of Great Cthulu, it's also used in some sick and warped protocols, which I need to support. Anthony
A snapshot of the stuff I have working is at: http://www.interlink.com.au/anthony/tmp/nonsuckhttp.py I'm not sure if this is the absolute latest version - will check tomorrow morning after sleeps. Anthony
On Sun, 2004-09-19 at 12:30, exarkun@divmod.com wrote:
Nevow imports Twisted. Therefore, Twisted should not import Nevow.
Incorrect. If nevow imports twisted.internet and twisted.web2 imports nevow that is fine since it is a different project. I think having twisted,web2 at least be semi-functional without nevow (i.e. importable and tests running) would be good enough for your concerns?
On Sun, 19 Sep 2004 22:02:35 -0400, Itamar Shtull-Trauring <itamar@itamarst.org> wrote:
If twisted.web2 provided a reduced level of functionality in the absence of nevow, that'd be fine. Good enough for me will be having the web2 tests skipped when its dependencies are not installed. Jp
participants (10)
-
Anthony Baxter -
Christopher Armstrong -
Cory Dodt -
Donovan Preston -
exarkun＠divmod.com -
Glyph Lefkowitz -
Itamar Shtull-Trauring -
James Y Knight -
Mary Gardiner -
Stephen Waterbury