Thanks for that very thorough dissertation of the state of the Pylons union!
I found it all a bit depressing, mind you, because I have chosen to build our application on a technological dead end framework (Pylons 1.x) But if there is some inherent architectural dead end to Pylons 1.x then I completely understand the necessity to moving to something else. However, I am a bit skeptical of the BFG stuff ... not because I'm worried of its technical capabilities or architecture but I'm worried about its usability and learning curve. Back when I began coding our app I looked at wiring in auth and naturally evaluated repoze who/what and authkit. Even though it appeared, from what I was reading, that repoze who/what was the more capable library it failed my 10 minute test miserably. Whereas, within a short period of time I was able to get something working with authkit. Of course I realize that there is sometimes tradeoff between ease of use and capability. Which is precisely why I chose Pylons over Django - I wanted to be able to swap out certain modules for others - I wanted a bit more flexibility. But I also remember experiences with Zope in the early days - I found the architecture fascinating and did spend considerable time to learn Zope but at the end of the day I stamped it over-engineered because it was just almost always easier to just cobble something together with mod_python and coding closer to the metal. It is similar to my Java/Spring framework experience. Fascinating from an academic viewpoint but at the end of the day it is just always easier to code something up with a lightweight language like Python. At the end of the day, the best designs usually turn out to be the simplest. I shall hold off on my opinions of Pyramids until I have a chance to play with it and I am truly hoping that it doesn't smell anything like Zope. Which brings up the point, where can we get our hands on Pylons 2.0 work? Cheers On 5 November 2010 08:05, Graham Higgins <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Kevin, > > > On 4 Nov 2010, at 23:44, Kevin J. Smith wrote: > > Someone pointed out pyramids to me ( >> http://docs.pylonshq.com/pyramid/dev/narr/introduction.html) and I am a >> bit confused with the relationship between pyramids and pylons. >> I have been using pylons for over a year now and have never heard of >> pyramids (and that includes passively following this mailing list.) From >> the page on pyramids it seems to suggest that pylons post 1.0 will be using >> pyramids? If so, statements like "no controllers" kind of frighten me ... >> and quite frankly most things that are Zope related frighten me. >> >> Anybody care to clarify? >> > > Steady the Buffs, Kevin --- and any other Pylons users who might currently > be going "Whoa?! WTF?". > > FACT: Pylons 1.0 is not being killed off in any way, shape or form. Your > apps will continue to work and Pylons 1.0 will continue to be supported for > the foreseeable future, (yea, even in perpetuity should you be able to lay > your hands on a standard deep-space, 6.4 megayear-rated gravity-powered > server like what we have). > > The "Pyramid development" is actually /very/ good news for Pylons users. > You may not be aware of it but Pylons 1.0 is currently in a developmental > cul-de-sac which offers no feasible route to a Pylons 2. > > When working through the Pylons 1.0 architecture, looking for a way to > allow Pylons to properly support extensibility, Ben recently discovered an > architectural design flaw in Pylons [1]. The problem orients around the > chosen strategy of implementing individual app extensibility by allowing > subclassing of the WSGIController. > > Ben says that Bob Brewer (of CherryPy fame) warned him about it at the > start of Pylons but back four years ago Ben was young, carefree and thought > little of it --- I'm paraphrasing, you understand :-) > > But now, after four years of development, it ultimately transpires that Bob > was right, one side-effect of this strategy is that it now profoundly blocks > the planned further development of Pylons and the strategy can't be changed > without an accompanying complete re-write of the Pylons codebase. > > Which is not going to happen, for two reasons: 1) it's too much work, in > the wrong direction and ii) all Pylons 1 apps would have to be > comprehensively rewritten to work at all with Pylons 2. > > So, with respect to Pylons' roadmap to the future, Pylons is between a rock > and a hard place --- but only with respect to the future. There may be > storm clouds may be looming on the horizon over /there/ but right here, for > Pylons 1 it's sunny and that will continue, so we can still all go out and > play. > > Nevertheless, Ben is faced with the very real problem of making a long > running jump and grab to get Pylons into a position where we can all start > moving forward again. > > Otherwise, like many corporate products, Pylons 1.0 will have to be > declared "feature-complete" and feature development would cease. There's > nothing wrong with that per se, I'm still using a 10-year old a Java app > that gives me WYSIWYG XML editing, wouldn't give it up for the world. But > I'm sure that a declaration that Pylons 1 was "feature complete" and "that's > your lot" would be received with bitter disappointment by those Pylons users > who were looking forward to basing future work on Pylons 2. > > The thing is, the BFG guys are already where Pylons needs to be, and they > are beckoning welcomingly and have been doing so for a while. > > From his omniscient position as Pylons BDFL, Ben is aware that some power > users have already hit the Pylons wall on extensibility and they've > abandoned Pylons in favour of BFG and what's more, they've found that they > love it. There's something of a steady trickle of advanced technical users > from Pylons to BFG and as Ben remarks: "that says something". > > In addition, Ben and Chris McDonough have been exchanging ideas and doing > experimental code sprints for years. Architecturally, BFG is conceptually > very similar to Pylons. Chris looked very carefully at Pylons when he > created BFG and if you read through his blog posts, you'll find a posting > titled "Tips for greenlighting a framework" in which you'll find: "Requiring > that a user subclass a framework-defined class is almost always the wrong > answer" [2]. > > Oh, the BFG guys might dress differently to us and their cuisine might > taste a bit different to us but basically BFG does pretty much the same > thing as Pylons does - takes some stuff (often in a db) and whacks it out > the door as HTML or whatever. > > BFG is WSGI-based, just like Pylons is; it is (broadly) MVC, just like > Pylons (broadly) is and, given a very similar base functionality (accept > request, connect request to code, execute code with in the context of the > req, return template-rendered result), you can see the attraction of taking > BFG's core and using it to replace the flawed Pylons one. > > For their part, the BFG guys are aware that their userbase so far has been > mainly ex-Zope users and a small (but gradually-increasing) population of > ex-Pylons users. It's true that the BFG guys are originally from the land of > Zope but from direct personal experience, I can say that they are almost > completely rehabilitated. > > Work it out for yourself: they're already at the place where Pylons needs > to go, so clearly they're nobody's fool. The truly great thing is that > they're willing to share - there's a /very/ clear perception that the > conjunction of Pylons|TG|BFG represents a significant opportunity to raise > the web app development game both in technical and functional terms. > > Specifically, there is a lot of developmental synergy between the three dev > groups. Of late, Ben has been taking nearly all of the Pylons development > load on his own shoulders and the addition of some more similarly > highly-talented, highly-skilled, highly-productive developers will seriously > elevate the Gestalt - a point which is not lost on BFG, they're very > encouraged by this development, too. > > Demonstrating a total lack of Zopish dogmatism, Chris has been putting in a > /huge/ amount of effort to partly dismantle BFG, strip out the stuff that's > BFG-oriented into a separate area (so as to not frighten the Pylons horses) > and reform the remainder as a common core suitable for supporting the > minimalist development style that is shared by /both/ Pylons and BFG. > Pylons-oriented code, developed earlier during exploratory joint code > sprints, has already been integrated (by Chris) and Pyramid is progressing > rapidly. Pylons 2 is looking very good indeed. > > There's /explicitly-planned/ space in Pyramid to support the TG community's > "full-stack" style too, should the community fancy jumping on board. > > "Leave no user behind" would be a good description of the current ethos. > > Personal tip as an ex-TG user: make the jump, it'll be a huge plus for TG. > You will finally be able to have composite applications (well, all Pyramid > users get that benefit). You can make a package that has your common > controllers, templates, models in it and easily re-use that in your other > sites. And if you need to customise how the package functions in one of your > new sites, you don't even need to fork the original. > > Were you looking enviously at Pinax? Well, with Pyramid, you will have > access to an explicitly-designed extensibility strategy that is integrated > with the framework, instead of one that was bolted on later as an > afterthought. > > Is that worth a bit of forbearance? Hope so, it is in my book. > > As work proceeded apace on the "common core" it became screamingly obvious > that the /really big/ opportunity facing the dev teams was a full-on merger > of the codebase. > > Having a "common core" supporting more than one web app development > framework has always been an elusive, strived-after goal but as soon as you > can stand in the foundations of such a development, the advantages of a full > merger become very clear indeed and, after a short discussion, a full-on > merger was settled upon. > > This allows the dev teams to converge on maintenance and development best > practices and provides a significantly more robust and (simply through > having more devs) more capable development team. > > The Pyramid codebase is an active building site at the moment, all dust, > sparks and scaffolding, there's a /lot/ of work going on as you can tell > from the commit history, so do wear a hard hat if you visit. > > > On 5 Nov 2010, at 09:34, daniel wrote: > >> had a quick look at pyramid ... too complex to me and not really >> understand for which benefits, which could not be handled with the >> lovely pylons .. >> >> I feel should consider whether it's time for me to step back to >> django .. I always hated zope (useless ?) complexity and I love simple >> way of thinking >> > > I shared your perspective, except that I was considering Clojure and I'm > not as bothered by Zope's software busywork. > > A couple of days ago I emailed Ben, saying much the same as you and in > response, Ben kindly disabused me of my many misperceptions and I'm now > totally sold on the move. > > I've decided to try and communicate the insights that Ben passed on to me > --- there's a certain flexibility of expression that can be achieved in > personal email but which is just totally unsuitable for "announcements" and > I'm trying to pass on those insights in turn, in a form that strikes an > acceptable balance between formality and facetiousness. > > One of my first self-appointed tasks is to try and communicate (in my own > idiosyncratic style) the benefits to the Pylons userbase. (I've only just > started on this task, so please bear with me while I get settled in with the > new codebase.) > > TBH, by far and away the main benefit is that Pylons once again has a > future and one which is hugely brighter than it was just a few weeks ago. > > I guess the benefit accrual process will probably happen over a couple of > stages. The first will be when users start to make use of all the > BFG-provided goodies which will be immediately available through the merger: > things like events, etc. > > (I need to go carefully through a whole bunch of saved posts, pulling out > the references to the goodies and making sure that I can express them > fluently in terms that I think Pylons users will readily understand.) > > I'm gonna fire this off now, 'cos I think an early response is indicated, > before things start to get out of hand, if they're heading that way. > > I'm working on a more considered, more detailed exposition --- there's a > long and continuous back story here that stretches back to mid-2008. > > I have the first part of an /unfinished/ blog post which I will be posting > later this arvo (in its unfinished state), just to add some broader context > to the upheavals that are currently going on in the Pylons 2 area. (I'll > post the URL here as a reply). > > Remember, Pylons 1 is NOT affected by the upheavals, only Pylons 2 is > affected and as Pylons 2 was only ever vapourware, your current operational > context will remain serenely undisturbed. > > What you're seeing is a cloud of dust thrown up by the construction site, > don't let it blind you to the superb (pyramid-shaped?) building that is > being constructed. Mike Orr is working to insert a layer of documentation > that is intended to be better attuned to the Pylons approach with which > we've become comfortably familiar and I'll be looking at taking some of the > Shabti templates and migrating them to Pyramid as well as providing my own > warped take on the documentation. > > I can personally assure you that Pylons users' concerns are an explicit > subject of intense attention by the Pyramid developers - as are BFG users' > concerns and TurboGears users' concerns. The Pyramid developers are waaaay > too smart to make the elemental mistake of riding roughshod over users' > concerns. > > (Who am I to give personal assurances? I am a cognitive scientist with a > Masters in Cognition, Computing and Psychology from Warwick University in > the UK and a career in commercial AI/Expert systems research in blue-chip > Labs (Marconi and HP). My domain specialisms in cognitive psychology are the > cognitive limits of attentional performance and cognitive issues in causes > of human error as applied to the domain of software engineering and > programming language design. I've been using Pylons for several years and > have contributed to the Pylons' documentation and training material, > developed Shabti, a set of Pylons "power-up" templates and I am currently > engaged in contributing to Pyramid in a similar context.) > > Finally, the BFG component of the Pyramid devs anticipated some of these > sort of questions and observations, so they prepared a response: > > http://docs.pylonshq.com/denials/pyramid.html > > :D > > [1] > http://be.groovie.org/post/1347858988/why-extending-through-subclassing-a-frameworks > > HTH > > - -- > Cheers, > > Graham > > http://bel-epa.com/gjh/ > > > > > > > > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAkzUHSAACgkQOsmLt1NhivxyBACgu/EXGJUwOkHsrLTH86x1YGS9 > dqYAoLp67Pd3/grjkW8XjqncL2xjvECsiQCVAgUBTNQdIFnrWVZ7aXD1AQKpxwQA > 4dK3mZJLVzOQ5lgX2ryAQ2CqfkqZ5ZM9StcQk5+rLz3S0yMO0iEdeQ2RhQ0m7Dfs > WuDUB2CF7cr2ztDhacCQhucRppZJmE3tn+k6kux0xqMHHc2jsV5E6B1bQDRfMXQt > +i4oszySQ6eNuHHsJcLKG1z/76GcZk7dFVhF/sU/Uj8= > =Jvel > -----END PGP SIGNATURE----- > > > -- > 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]<pylons-discuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- 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.
