Well said. I have a major TG1 app running which I tried to convert to TG2 - and now I'm happy I didn't. There was a huge, huge issue with porting from TG1 to TG2. Some the fault of TG2 being based on completely different principles, some the fault of dependencies which sure did their share of abandoning code and moving forward too.
For me the SLQAlchemy dependency and switch from 3.x to later versions was one of the big killers (not a TG fault), the other one was the majorly different handling of sessions, identities and authentication. If you have a code-base of close to a million lines, you don't want to sift through every file and replace an identity - the chance you miss one is too big and has disastrous results if someone now can do things he shouldn't be able to. So I'm still on a patched version of TG 1.0.3 simply because I wasn't able to port it with a reasonable effort to a later 1.x version or even a 2.x version. Porting to 2.x would basically have been a re-write for something that took me 12 months to write and test in the first place. I know you can't do anything about the SQLAlchemy project releasing new, backward incompatible versions (although that was a major point in me not moving to TG2, because it would have required to rewrite and test every query in the system. Personally I don't like ORM's and you might, rightfully so, say "don't use one" - if it wasn't for hundreds of templates that use a tablename.column syntax - which is very convenient.) There is however the whole session and identity issue. If you run a website that heavily depends on access rights and identities in general, you don't want to change thousands of lines using a "py:if="tg.identity.anonymous" type of syntax. I have no grief about this because I've been in the "open source" business even before linux was a word. I do however think that a backward compatible layer on top of the new repoze.who and repoze.what packages would have made transition much much easier. I abandoned the move from TG1 to TG2 exactly for that reason - at the point when I tried (2.1) it was just not worth the effort to either write a compatibility layer or change tons of code. Members crave new features, not new technology providing the same features. My perspective may be a bit scewed, because my livelihood depends on that website. Knowing that users have no respect for new and improved "technology behind the scenes" - which basically doesn't provide anything new for the average user to toy with - I decided to rather continue using heavily patched old versions of TG1.0.3 to achieve what I need on the frontend side. This is a "user" perspective of things. I have no problems with tons of dependencies etc.. Installation never was an issue for me. Backward compatibility or at least a clean, documented, path of transition however is. So I guess I'll see what pyramid brings along. In the end I'd love to use new or better features that perform better. On the other hand I can't mess with 15.000 plus paying members in favor of a "technically better" technology the members don't see. So I may or may not be stuck with old 1.0.3 for the next years. I know, this doesn't sound very community / open source - friendly. I'm too constrained on staying afloat to put in big contributions in time and code, but I'm happy to give a migration to a new TG type environment a shot and report back on the issues. So count me in as a tester... Uwe > Whao. Quite a bite to process here. > > Let me begin by saying that I deeply respect the efforts various > people have put into TG over the years. And successfully so in many > respects. I myself have so to varying degrees, and it was a good > experience. > > Also I'm very in general very satisfied with the technical aspects of > TG2. I personally don't care about documentation (use the source, > luke), and thus have always been able to unleash it's powers. > > But since the advent of TG2, TurboGears as whole has been declining in > community and overall adoption. And I believe this is due to 3 major > factors: > > - the early announcment caused anxiety in the community. If you plan > on starting a new project, you don't want to invest into "old" > technology. But the new, shiny TG2 arrived later than expected. > - splitting the development force. Some of us were committed to TG1, > as they had large installations. Others jumped onto the TG2 bandwagon > - the overall tendency of developers of TG2 not to stick with > existing dependencies or approaches, but instead to go for the "next > big thing". See for example > KID -> genshi -> mako -> jinja, TGWidgets -> ToscaWidgets -> > ToscaWidgets2 -> Mark's Widgets (sorry, forgot the name), TG Admin -> > Sprockets -> SPROX -> TG Admin again (I'm unsure with the last list, > never cared much about these things) > > As a result of this, I think we couldn't create enough of an eco- > system of 3rd-party contributions in terms of pluggable apps, > documentation writers, community and so forth. > > Another "issue" is built-in, and partially reflected above already: > the best-of-breed-and-lots-of-dependencies approach has benefits - but > also downsides. Documentation is split, bugs span across frameworks > and packages, releases need careful testing and packaging, whole > packages depending on one single developer - who might lose interest > or can't contribute anymore - and so forth. > > And now this new route. I understand it. I see chances for having a > larger development force behind it, and thus to mitigate quite a few > aforementioned problems. > > But it will provoke the same anxiety, it will leave those of us behind > that have existing TG2 installations (let alone TG1). And please don't > pretend there will be a reasonable stable way to make the next big > thing backwards compatible. TG1 vs. TG2 has proven enough that this is > harder than one might think, and it's debatable if it is a worthy goal. > > So, to wrap it up: I won't and can't speak out against this move - you > guys do, what you do. It's a technically sound decision. I will keep > an eye on what comes out of it. I might even move my existing projects > over to it (but then, there are 10 developers working with TG2 now - > that's a *lot* of brain to shift around) > > But IMHO selling it under the turbo-gears brand is a mistake, or at > least misleading. Call it something fresh, something new, attract a > community - and try & stick with it, instead of moving faster than a > large group of people can. > > From a technical POV, I strongly hope that you stick with WSGI as the > glue that binds things together. To me, it's a close-to-perfect > abstraction that cuts the various aspects of a web-app on clear, yet > still powerful interacting components. > > Also, composable apps would be a great thing I guess. > > And last but not least, keep or even ramp up the focus on testing, and > testability. TG2 is already much better in that respect from a user's > perspective, but the last sprint showed that testing the core is > harder than one might want it. > > All in all - no hard feelings. But no excitement either - to much good > work is down the drains due to this IMHO. > > Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en.
