This has been a fascinating discussion! I don't have anything to add that hasn't already been expressed, but I second Kevin's request to try it out and see how it works.
More specifically, to the developers: do you need testers? I'm planning some updates to one of my side-projects, and I'd be happy to try rebuilding it in Pyramid to see how it goes. It's something I'm doing on the side for fun so I can work on it whenever you're ready for testing. On Fri, Nov 5, 2010 at 11:36 AM, Kevin J. Smith <[email protected]> wrote: > 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]<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.
