I'm glad to see (vis a vis this discussion thread) that the elephant in the room now has a bright light shining on it.
As soon as I caught wind of repoze.bfg and now pyramid, I put a couple of hours into reading through the docs. To me it was apparent even at first look that the new ontology is more straightforward, and we will be able to put new apps together even more clearly and simply than ever. Nothing struck me as more complicated. All I see is more options and a very significant success in simplifying and clarifying the tasks that a developer has to go through to get his app or site up and running. I'm not surprised the news is shocking to some, but the new direction makes me very happy. I never really felt at ease with how much Pylons configuration was tucked away in multiple python files. Any time I took a break from Pylons for a few months, when I came back I invariably had to read through Mike's execution analysis to wrap my head around what was actually going on and why some configuration was here, some was over here, and some was in yet another place. Three cheers for Pyramid. Now how long before someone writes a build template for it and calls it Cheops or Khufu or some other famous pharaoh's name... - Eric On Nov 5, 3:10 pm, Ben Bangert <[email protected]> wrote: > On Nov 5, 2010, at 1:50 PM, Jens Hoffrichter wrote: > > > 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) > > No worries, these are not dead! The WebHelpers package isn't going anywhere, > and its still easy to use throughout your templates. > > > - Change in how to address a template (from "package.template" to > > "package/template.mak") > > Ah, sorry if that's confusing. The dotted notation for a full 'resource > specification' is > optional:http://docs.pylonshq.com/pyramid/dev/narr/views.html#mak-or-mako-mako... > > You can and do of course, configure Mako to have a template directory, and > relative names like 'foo.mak' are assumed to exist in said template dir. > > The ability to use a full resource specification addresses a long-time noted > issue with extending or re-using packages of your templates. While Mako lets > you plugin multiple template paths, the overlap can get tricky to manage, > being able to refer to a template with its package name is specifically to > allow you to use templates that might be in another package for extending > purposes. > > Consider the case where you have a set of templates you use in all your > projects, wouldn't it be nice to have a package of those you just call into? > And if you needed to tweak just one of those, you could override it with a > template of your choice via the override > API:http://docs.pylonshq.com/pyramid/dev/narr/resources.html#the-override... > > This is the start of where many frameworks are telling you to fork code.... ;) > > > - The move from implicit routes to explicit routes > > Yes, all routes do have to be explicit. I was moving that way in Pylons 1.x > with Routes already actually, as the implicit naming and resolving done in > Routes generally leads to more problems for users, than helping. > > > 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. > > I've tried to provide as smooth an upgrade path as possible between various > versions of Pylons. From the upgrade path's I've seen in other web > frameworks, its one of the smoother ones... but the fact that so much > configuration was in Python files rather than the framework has been very > problematic as extensive changes are needed for upgrades as half the > 'framework' is more or less assembled in the project itself. pyramid does not > have this issue, as rather than having all its configuration innards in your > project, you configure pyramid via hook points. > > > 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 :) > > http://be.groovie.org/post/1347858988/why-extending-through-subclassi...is my > main summary of the problems. > > I also have a bit more on this on the faq question > here:http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue... > > > 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'd love to spend more time on getting an 'official' one hammered out. Part > of the reason for combining efforts, and going with pyramid for the base is > that we need a strong, stable, extensible system to start building more > helpful higher level tools. With a larger team of developers, this becomes > much easier. I'm also trying to address ways the Pylons site failed to make > it easy enough to get involved and contribute by increasing the amount of > documentation on *how* to actually > contribute.http://docs.pylonshq.com/#contributing > > So far, there's already a lot more developers working on pyramid, and the set > of libraries extending up around it than Pylons managed in the first several > years of existence. I really believe that before long, there'll be a set of > such compelling libraries for use with pyramid, this issue will be a > non-starter, and you'll have a great case to make for clients on why they > should port that wasn't nearly as easy to make for moving from Pylons 0.9.6 > -> 1.0. > > Cheers, > Ben -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
