-----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 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.
