There's no doubt that other frameworks are bigger, more widely used, and more popular. No argument from me of any sort. Arguing in favor of a merger by stating "We have a better chance of taking down Django" is not a useful argument, though, not for me.
I don't devote the time I do to take down Django. I don't do it for money. I don't do it for fame. I don't even do it to help other projects improve, or reach any of those goals. I do it because I love TurboGears. This web framework is the first one I ever found that actually made *sense*. I'd tried others. I'd even written my own really bad one in PHP in the early 2000's. None of them ever felt wholly right, though. Always, some aspect was poorly done, or some piece always got in the way of my project, or the entire system just seemed designed to make easy tasks complex, and hard ones virtually impossible. TurboGears provides something that others have always seemed to lack: just the right amount of simplicity. When I go to work on a TurboGears project, I can navigate it easily. I can find and deal with the various pieces, and feel comfortable that I am actually finding what I need to find. When I need to make a change, I can feel comfortable that I am changing the right piece of code. TurboGears provides these things for me, and it makes coding with it into a joy. Arguing in favor a merger on the grounds that everybody can topple the Django beast will not sway me. I love what we have, and I feel that the future is bright. It's not an easy row to hoe, to be sure, but few things worth doing are. All of that said, I'll address the rest of the points, and reply to everybody. On Sun, Jul 8, 2012 at 2:28 PM, Lukasz Szybalski <[email protected]> wrote: Assuming that we did the merger work, we would have some piece of code called TurboGears that is based on Pyramid. Keep that in mind for these responses. --Features that pyramid is capable of would work by default in turbogears, > no rewrite of code would be required to take tg2 into python3 for example, > take the speed improvements, etc... > Unfortunately, this is not correct. We would be vulnerable to which specific version of Pyramid we coded against. If a benefit from Pyramid required changing the way we use an API, we could not gain that benefit until we updated the code. If a backwards incompatible change were made in Pyramid, we would have to update our code to fix it, or lock down which version of Pyramid we support. If we found a problem in Pyramid, we would have to rely on Pyramid to update before we could truly get it fixed. Furthermore, while Pyramid may be Python3 ready, we are not. Pyramid being ready or not has no bearing on whether our code is ready, and that's true regardless of anything else that may be going on. This pro has some benefits, to be sure, but it's not the bed of roses that is painted here. > --All the components that were mentioned above from repoze.XXX would still > be valid and would follow pyramid upgrades and no additional work would be > required to get them working. > The same problems and benefits as the previous item. > --Any changes to Paste would already be done in pyramid. > While this is true, since we're not at that point in our own development. As such, this item is not a consideration for us at this time. In future, maybe, but right now, no. > --Turbogears choice of most downloaded components as a default would bring > over few users that have high learning curve because of pyramid default > scaffolds selections. > Agreed on this point. This would help Pyramid adoption, definitely. > --More consolidation would mean more of most common packages would be > available to users. > For consolidation, what I would actually look to provide is some way for modules to seamlessly make themselves available for multiple frameworks. For instance (and this may be a bad example), if we were to provide a "webframework.model" entrypoint, and all the frameworks were to honor it, then a given plugin could make it's model accessible without caring about who it's written for. That would allow for consolidation, without requiring that everybody join with a specific web framework or be invisible. > -- Instead of splitting from pylons embrace the evolution of pylons would > mean more users are reassured tg2 is the right choice to build on. > Does it really? If someone is trying to make a choice, then wouldn't "Built on Pyramid" being on everybody's site be more of a vote for any users to go to Pyramid, instead? If the number of users mattered to me, this would actually be a detriment to TG, not a bonus. > Cons: > -- Some work is required to replace pylons components with pyramid > An unknown amount of work for a benefit that may not materialize for the TG framework. That's a high risk proposition to me. This particular item is a bigger detriment than I feel you give credit for it being. > -- Some tg.ext would need to be updated to support new changes. > Actually, many of them would. For instance, tgext.menu and tgext.xmlrpc (my own two) would probably be broken. tgext.admin stands a good chance of being DOA as well. And that's the major ones I can think of off the top of my head. > -- Core developers would have to go a little outside of their comfort zone > by not just "being happy" with current state of tg2 but to take it to the > next level. > This "con" is also (albeit unintentionally) insulting. It makes a pair of assumptions that are not at all kind: We don't work outside of our comfort zone. We're incapable of taking TG to the next level. Neither of those statements is true. Alessandro is working hard to prepare for Python3. I'm working on ideas that I can't even fully articulate yet (go read my G+ stream if you want to see). Our "comfort zone" is slightly restrictive, I admit. I prefer working with Python to working with Java. Outside of that, my attitude is "I have a problem. Now to solve it." I have no problem working on ideas that are decidedly not normal. I won't speak for others, but I'm pretty sure they feel the same. As to whether or not we're capable of taking TG to the next level, that remains to be seen. It also remains to be decided what the next level *is*. If the definition is "massive following, dethroning Django", then no, I'm not capable of that. If the next level is "Making TG do things that others will look at, and be impressed, and ask me about TG and why I feel it's the best choice", then yes, I can do that. I have good ideas. They will happen. > -- Won't be able to "design" the new framework to replace pylons part, but > rather will need to include already written software. > Not too much of a con either. After all, take a look at the number of packages we make available and use. We have too many libraries. I'd like to reduce our dependencies before we extend them again to include something else. > Would developers consider following the evolution of pylons and including > pyramid into turbogears? > We have. We've considered it a lot. At one point, I even openly advocated for it, as much as I hated the idea personally. Why? I felt that it would be a good thing. And I started to leave the project behind, because it would no longer be the project that I loved. I saw no future for me with it. Then, thankfully, Christoph emailed me, personally, and asked me what my plans were. I had to confront my own issues with the merger, and I realized that, even though the merger could go on, that didn't mean that I, personally, had to. TG2 still had (and has) life in it. I love it. Even with all the turmoil I've dealt with over the past year, I've loved this project. I kept coming back to it mentally. I want to work on it, work with it, and show people how great it is *right now*. I, personally, am not ready for a merger. I'm not going to be ready for a while, either. That does not preclude collaboration. I can easily working with, and helping each other. We can figure out what we need to see by way of widget libraries, or database access layers, or whatever else. But for me, for now, the merger is not something I can get behind. As it turns out, I reiterated much of what Alessandro said (though in more verbose form), so I'm not going to reply to him. No point :) On Sun, Jul 8, 2012 at 4:48 PM, Christoph Zwerschke <[email protected]> wrote: > Also, if TG would make another radical change now, we would again come > into the situation where people start asking "shall I use TG2 now or shall > I wait for when TG3 based on Pyramid appears", and start wondering whether > they will be able to migrate their TG2 apps. > One of the situations I want to avoid is one that happened early on in my involvement. 2.0 was going through a beta cycle, almost ready for release, but people on the ML and in IRC were telling everybody to go to the 2.1 that was still in development, not even at beta. This is not a good situation, and during any sort of merger period, that's where we'd be (well, unless we stopped everything for TG2, and declared it dead, while we release Orion/TG3. Obviously, that's not a good choice). > Lastly, everything also depends on the time and energy the core developers > have at hand, and that is very limited. Mark, who orginally came up with > the plan of a merge, wasn't able to spend time for the project any more. > Currently only Alessandro and Michael are actively working on the project. > Maintaining what we currently and developing that slowly and carefully is > already enough work. I think they're doing a good job, and I like that TG2 > is moving more steadily now and less jumping around with new ideas and > changes every other week. I've been slack for a long time. Work had a profound (and negative) effect on my personal life, and that limited my ability to self-motivate and work properly on TG. As you can see, that is changing a bit. The new job is decidedly healthier for me and for TG. -- Michael J. Pedersen My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen Google Talk: [email protected] -- Twitter: pedersentg -- 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.
