Hi all, Thanks to especially Graham and Mike to point out what the benefit for the "end-user-developer" (a crude term, I know ;) ) will be with the Pylons2/Pyramid move.
When I started to read these posts, I was a bit concerned, too. I (we, my company) have been long time Pylons users, and admittedly, we have seen more changes in Pylons than we liked. I could understand the reasoning behind all those changes, still, for the developer they pose a hazard in long-term-evolution of a written app. Some of the things I mean: - The deprecation of rails-style webhelpers. We depend on those quite a bit in our first application we wrote (and which is still live) - Change in how to address a template (from "package.template" to "package/template.mak") - The move from implicit routes to explicit routes And if I thought a bit more, I would probably come up with a couple of more examples, which have been problematic for us. The problem in there is, that there normally is no smooth upgrade path, and no backwards compatibility, so we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, as no one would pay us a money for the complete rework the older apps need, as for the customer, it would mean very little benefit. Don't get me wrong, I love pylons, and the first question we ask ourselves when a new project comes in is, "Can we solve this in pylons, or do we have to implement it with something different?", but the lack of continuity has been a bit disheartening at times. Still, I would really be interested in why the subclassing of WSGIController lead Pylons in an architectional dead end, just from a curious point of view :) I will take a look at the new packages as soon as I get around to it, but I'm really curious by now. > But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies. > "@validate" needs a replacement; that's the only thing I can think of. Maybe not the Pylons package itself (and I personally had no trouble using @validate up to now), but one thing the whole Pylons eco system would hugely benefit from (imo) is a database migration tool. I have looked into those which have been announces (miraku and a couple of others), and all fall short. I have written something like that for ourselves, for SQLAlchemy based projects, which takes the model, evaluates the differences between the current model revision, and the latest from the versioning system, and generates the appropriate SQL scripts for getting the database from the one version to the next, without loss of data. I always hoped of releasing it to the public at some point, but I never really had the time to get around to it. It is stable we are using it for a couple of our projects, but it is lacking the real hard stuff (like documentation, and things not that tied to our own infrastructure ;) ) Regards, Jens -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
