Notes on Pylons 1.x code-base and the Pylons Framework
Ben Bangert
framework in light of new effort being spent around additions to Pyramid. I
thought it'd be useful to help assuage those fears, and explain a bit more
about the Pylons code-base.
Pylons 1.0 was released 6 months ago, in May of 2010. Between 1.0 and 0.9.7,
which were released over a year earlier in Feb. of 2009, there were almost no
changes to Pylons besides deprecated bits being removed, and a few defaults
changing. Most new features instead came from changes to Beaker, SQLAlchemy,
WebHelpers, and occasionally Routes.
Beaker, SQLAlchemy, Mako, and WebHelpers are unaffected by Pyramid: they
continue to work as they have. Pyramid can use most of these packages just
like the Pylons framework can. (A few webhelpers are currently incompatible
with Pyramid: see pylons-devel). As these packages are also where most of the
feature improvements for Pylons framework users came from, again, there's no
change in that!
Nothing is changing regarding the Pylons 1.x code-base from how it has been
for the past year and a half. It is a mature and stable code-base that meets
many people's needs. There's no reason to feel bummed or sad that it is
somehow 'dead' or 'end-of-life'. It will continue to receive the same bug
fixes and security fixes that it has been getting for the past 18 months, in
perpetuity.
Pyramid really only affects where myself and some other Pylons developers will
be spending our future development efforts. As a stable and mature code-base,
the Pylons framework has required a lot less of my attention lately, so my
current development time spent on it has already dropped quite low. The
development time I spend on the Pylons framework is not changing. With that
freed up time -- and additional developers through this merger -- we can spend
more effort and resources pushing ahead with Pyramid-related development. One
thing we're doing is increasing our scope to tackle larger problems that were
beyond the scope of the Pylons framework.
The existing amount of time I've been spending on the Pylons code-base for the
past 6+ months is not changing. The Pylons 1.x code-base is not changing, apps
using it will continue to run. But with a larger development effort, we'll be
able to build some useful additions that should help people whose needs
haven't been completely met by the Pylons framework.
Cheers,
Ben
Ev Kontsevoy
Pyramid brings a strong "java odor" in the form of XML-based config.
Why? Put views in views directory, models go to models and handlers to
handlers. Why infect our world with XML? And even if someone needs to
be verbose - use Python for it, its nicer! XML has no place in the
world of dynamic languages, its not "declarative" vs "imperative",
it's "dumb" vs "normal".
Not loving Pyramid at all. It's not bad, but it needed to be AMAZING
to justify killing Pylons. Sorry to say this, but Pyramid is not it.
Look, people had reasons to pick Pylons over Repoze. We don't like
anything Zope, we don't like Repoze and we certainly can't stand XML.
Now you've renamed Repoze to Pyramid and offering us to upgrade or
shut up.
Please, please please: stay away from Repoze guys. :-) They're bad
influence. Don't pick up the phone when they call. You have a much
nicer framework (Pylons). You have users who love you. Don't push us
away!!! :)
Cheers,
ev
Eric Ongerth
Surely you read enough of the docs to see that all declarative
configuration in Pyramid is optional? The option to configure
everything nearly the same as Pylons currently does it is right there
and it is given equal treatment.
Why do you describe the current plans as "killing Pylons" when Pylons
will continue to be fully functional through Pyramid?
Eric
Ev Kontsevoy
I have spent half of my saturday to read every single page on
http://docs.pylonshq.com/pyramid/dev and I am not seeing anything
pragmatically beneficial there compared to Pylons 1.0
The only area where Pylons needed help, where it was ages behind
Rails, was FormFill/Encode. It was by far the biggest blemish on
otherwise neat package for building web applications with Python.
Pyramid does not address this at all. Its just a bunch of class/method
renames without obvious pragmatic benefit.
I know that XML is optional. But why? Why is even there? One could
have killed Pylons and said "look, pyramid has a built-in MP3 player!"
- how's that helping? Both Pylons and Pyramid introductory pages say
something "we have looked at Django, Rails and XXX and combined the
best YYYY in ZZZ..." Excuse me gentlemen, but have you looked at
Rails-3? Seriously, have you SEEN what can be done with concise
routing syntax and naming configuration? It doesn't help it one bit
that XML is optional. Pylons wasn't about being a kitchen sink of a
framework - it was about being small and lightweight.
Web framework in 2010 is supposed to do this:
resources("cars") # <--- see there? that one line was supposed to give
me /cars and /car/id for GET, PUT, UPDATE and DELETE requests,
complete with views and default controller actions. People don't use
truckloads of XML to define those basic CRUD routes and views, not in
2010
Another thing web frameworks are supposed to do in 2010 is to define
an HTML form which DOES NOT need to be parsed on the server and pre-
populated with dictionaries of values to display a validation error.
Also, a new web framework in 2010 should not be re-inventing Request
and Response objects. What was wrong with Paste?! In 2 years reading
Pylons-Discuss I have never once (!) seen any complaints about WebOb.
Why is Pyramid brings yet another variant of response/request?!?
I can go on and on and on - I have read Pyramid docs. They're already
obsolete, just look at this:
@view_config(renderer='templates/foo.pt')
def my_view(request):
return {'foo':1, 'bar':2}
So now if I need to return XML or JSON I need another view? Again, if
you claim you "borrowed best of rails", I invite you to take a look at
how Rails-3 does it:
def my_view()
respond_with {'foo' => 1, 'bar' => 2}
end
And works great for /my_view.xml, /my_view.json and /my_view.html all
at the same time. I guess you will use that as an excuse to throw away
Pyramid and launch Pyramid-2 based on something entirely different 2
years down the road.
Also, if "stacked proxy globals" were such a big problem, why still
have them? When I saw "configurator.start()" I immediately could smell
something fishy. Just the fact that you have "doer" classes ending
with "or" and having methods like "start" and "stop" tells a lot. This
may not be that bad, but not SPECTACULAR, and spectacular is what you
needed to justify killing of Pylons. Pylons was __amazing__, it just
needed a better form handling package.
Ughh... This feels like a step backwards. Honestly, using barebone
Paste looks like a best web framework right now. I wonder if Ian had
anything to say about Pylons development vector.
I suspect quite a few Pylons folks will be unhappy. We already saw (!)
Repoze when we were picking our framework. And we didn't like it. We
preferred Pylons. See, we already voted! I don't want XML junk or
built-in authentication even if they're optional. I want a powerful
glue between declaring resources that bind views/models/controllers
together, based on common conventions as opposed to low level
decorators, XML diarrhea or "imeratve" add_view() assmebly. That's
just as low level as basic Paste which is small and nice.
Chris McDonough
> Eric,
> I have spent half of my saturday to read every single page on
> http://docs.pylonshq.com/pyramid/dev and I am not seeing anything
> pragmatically beneficial there compared to Pylons 1.0
>
> The only area where Pylons needed help, where it was ages behind
> Rails, was FormFill/Encode. It was by far the biggest blemish on
> otherwise neat package for building web applications with Python.
> Pyramid does not address this at all. Its just a bunch of class/method
> renames without obvious pragmatic benefit.
>
> I know that XML is optional. But why? Why is even there? One could
> have killed Pylons and said "look, pyramid has a built-in MP3 player!"
> - how's that helping? Both Pylons and Pyramid introductory pages say
> something "we have looked at Django, Rails and XXX and combined the
> best YYYY in ZZZ..." Excuse me gentlemen, but have you looked at
> Rails-3? Seriously, have you SEEN what can be done with concise
> routing syntax and naming configuration? It doesn't help it one bit
> that XML is optional. Pylons wasn't about being a kitchen sink of a
> framework - it was about being small and lightweight.
Can't really say much more except that it's totally optional. That
should be clear from the docs.
> Web framework in 2010 is supposed to do this:
>
> resources("cars") # <--- see there? that one line was supposed to give
> me /cars and /car/id for GET, PUT, UPDATE and DELETE requests,
> complete with views and default controller actions. People don't use
> truckloads of XML to define those basic CRUD routes and views, not in
> 2010
Ben does have plans to create a package that will make this pretty
simple. It's actually even mostly done on the Pylons trunk, although we
decided to not put it into Pyramid (as its API is a based on route's
map.resource, which seemed a little weird).
> Another thing web frameworks are supposed to do in 2010 is to define
> an HTML form which DOES NOT need to be parsed on the server and pre-
> populated with dictionaries of values to display a validation error.
Form generation is not in the scope of Pyramid. OTOH, there are plenty
of excellent form generation packages from which to choose that work
fine with Pyramid. We (loosely, we, meaning really me and Ben, I guess)
do have intent to build higher-level frameworks with Pyramid that will
fill this role.
> Also, a new web framework in 2010 should not be re-inventing Request
> and Response objects. What was wrong with Paste?! In 2 years reading
> Pylons-Discuss I have never once (!) seen any complaints about WebOb.
> Why is Pyramid brings yet another variant of response/request?!?
It doesn't. Within pyramid.request:
from webob import Request as WebobRequest
class Request(WebobRequest):
....
Within pyramid.response:
from webob import Response
Response = Response # pyflakes
>
> I can go on and on and on - I have read Pyramid docs. They're already
> obsolete, just look at this:
> @view_config(renderer='templates/foo.pt')
> def my_view(request):
> return {'foo':1, 'bar':2}
>
> So now if I need to return XML or JSON I need another view? Again, if
> you claim you "borrowed best of rails", I invite you to take a look at
> how Rails-3 does it:
>
> def my_view()
> respond_with {'foo' => 1, 'bar' => 2}
> end
>
> And works great for /my_view.xml, /my_view.json and /my_view.html all
> at the same time. I guess you will use that as an excuse to throw away
> Pyramid and launch Pyramid-2 based on something entirely different 2
> years down the road.
@view_config(name='foo.html', renderer='templates/foo.pt')
@view_config(name='foo.json', renderer='json')
@view_config(name='foo.xml', renderer='myxmlrenderer')
def my_view(request):
return {'foo':1, 'bar':2}
>
> Also, if "stacked proxy globals" were such a big problem, why still
> have them? When I saw "configurator.start()" I immediately could smell
> something fishy.
You can indeed get the request as a threadlocal in Pyramid. But you
don't *import* any threadlocals in pyramid (which is what SOPs allow you
to do).
> Just the fact that you have "doer" classes ending
> with "or" and having methods like "start" and "stop" tells a lot. This
> may not be that bad, but not SPECTACULAR, and spectacular is what you
> needed to justify killing of Pylons. Pylons was __amazing__, it just
> needed a better form handling package.
>
> Ughh... This feels like a step backwards. Honestly, using barebone
> Paste looks like a best web framework right now. I wonder if Ian had
> anything to say about Pylons development vector.
>
> I suspect quite a few Pylons folks will be unhappy. We already saw (!)
> Repoze when we were picking our framework. And we didn't like it. We
> preferred Pylons. See, we already voted! I don't want XML junk or
> built-in authentication even if they're optional. I want a powerful
> glue between declaring resources that bind views/models/controllers
> together, based on common conventions as opposed to low level
> decorators, XML diarrhea or "imeratve" add_view() assmebly. That's
> just as low level as basic Paste which is small and nice.
Can you tone it down a bit? I'm afraid your indignance is derogatory
and insulting.
- C
> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>
Ev Kontsevoy
>Can you tone it down a bit? I'm afraid your indignance is derogatory
>and insulting.
lost to K-State, can that be my excuse? :-)
Rocky
Second point - http://docs.pylonshq.com/pyramid/dev/designdefense.html
Conclusion, don't dismiss technologies just because brands (ie repoze)
associated with it.
- Rocky
Mike Orr
concerns (XML, Zope) above practicality. All of the core Pylons,
TurboGears, and BFG developers, and Ian Bicking -- have been working
on this project jointly for two years. It was called
"Pypefitters/Pipefitters", "Pypes", "Marco", and "Pylons 2" at various
stages. The developers all agreed it's a quantum leap ahead in terms
of improving Pylons' modularity and abilities, and in unifying the
Python-WSGI landscape. And we're keeping all those ugly XMLisms and
nasty Zopeisms away from application writers.
No previous framework has provided built-in primitives for all the
programming styles that have emerged among the various post-2005
frameworks (traversal vs URL dispatch, "return render" vs decorators,
class-based controllers vs a tiny function-based app that can fit in
one module, etc). That was the original goal of Pypes. Pyramid's
multiple modes allow almost any Python-WSGI framework to be built on
top of it, which could provide a new level of unification among
frameworks. The component architecture allows applications and the
framework to be extensible in ways that weren't previously possible.
Can you at least accept the possibility that *maybe* all these
developers know something you don't, and that if they feel so strongly
about Pyramid, there must be something good about it? I can't explain
the advantages as well as Ben or ChrisM so I'm not going to try. But
they are trying to explain it, and they'll get better at it over time.
Can you attend PyCon next March in Atlanta? Then we can discuss the
advantages and disadvantages of Pyramid in person with all the
developers together. There will surely be Pyramid open spaces and a
sprint, and we can even have some kind of "Is Pyramid good or bad for
Pylons?" open space if there's enough interest.
Again, your concerns are the same ones the Pylons developers raised
with ChrisM two years ago. "Ewww, XML! Zope = bloat." But after
thinking about the impacts of a component architecture -- and how
they'd otherwise make Pylons enhancements without it -- the developers
became convinced that it was a good thing, even if it meant admitting
ZCML and Interfaces. A component architecture (ZCA) provides a
standard way to extend anything via plugins. Without it, Paste had to
use entry points, and Buffet (a templating front-end used in Pylons
0.9.6-0.9.7) had to write its own thing from scratch (and it sucked),
and Repoze.who/what had to manage its plugins on its own -- all three
doing it a different way and reinventing the wheel. With ZCA, all
these can be configured the same way, and parts of the framework (like
Routes and Beaker and the thing that calls the controller action) can
also be configured that way, and new extensions can be added to Pylons
the same way, etc. Zope makes it easier for Ben to write enhancements
he'd wanted to do anyway, like to make Pylons applications more
nestable inside other Pylons applications -- something that Pylons
should do better but the current architecture gets in the way.
On Sat, Nov 6, 2010 at 7:00 PM, Ev Kontsevoy <eug...@gmail.com> wrote:
> Ben,
>
> Pyramid brings a strong "java odor" in the form of XML-based config.
> Why? Put views in views directory, models go to models and handlers to
> handlers. Why infect our world with XML? And even if someone needs to
> be verbose - use Python for it, its nicer! XML has no place in the
> world of dynamic languages, its not "declarative" vs "imperative",
> it's "dumb" vs "normal".
XML is a tool. It's ugly but it can do some things better than other
tools. I'm sure it's possible to create a YAML-based or Python-based
alternative to ZCML, because it all has to be converted to Python
objects in the end. But somebody would have to take that on as a
project. Anyway, Pylons-style Pyramid applications are configured
imperatively (in Python modules). If there is any ZCML at all, it's at
a low level inside the framework, not anything you'll see.
> Look, people had reasons to pick Pylons over Repoze. We don't like
> anything Zope, we don't like Repoze and we certainly can't stand XML.
> Now you've renamed Repoze to Pyramid and offering us to upgrade or
> shut up.
Or continue to use Pylons 1. Or fork it if you want to make a
different kind of Pylons 2. Pylons is not "dead", it just won't be
changing except for bugfixes and maybe backports. And that's good for
the subset of users who want long-term stability above anything else.
> I am not seeing anything pragmatically beneficial there compared to Pylons 1.0
There are other concerns besides user-visible features. Developer
convenience, maintainability, and the ability to give you shiny new
features in the future are also factors. One immediate feature is a
built-in auth system, which is (reportedly) easier to configure than
Repoze.who/what.
> The only area where Pylons needed help, where it was ages behind
> Rails, was FormFill/Encode. It was by far the biggest blemish on
> otherwise neat package for building web applications with Python.
The only area where Pylons needed help... FOR YOU. Other people have
different needs, such as making Pylons apps more nestable, getting
away from the magic globals, making apps more plugin-friendly.
switching out parts of the framework for alternative APIs, etc.
> Pyramid does not address this at all. Its just a bunch of class/method
> renames without obvious pragmatic benefit.
There will be application templates configured for several form
libraries. They may be in Pyramid or Shabti or in their own packages.
Pyramid is just going a little lower level in this area, because not
everybody liked the mandatory FormEncode/WebHelpers dependency --
including you it sounds like.
> I know that XML is optional. But why? Why is even there? One could
> have killed Pylons and said "look, pyramid has a built-in MP3 player!"
A component architecture is not like an MP3 player. It's like
replacing a 386 chip with a 686. ZCML is just the format that came
with the architecture -- sorry, but it has been the format for 12+
years.
> Excuse me gentlemen, but have you looked at
> Rails-3? Seriously, have you SEEN what can be done with concise
> routing syntax and naming configuration?
I personally haven't looked at Rails. Could you make a list of Rails-3
features that would benefit Pyramid, and file a bug report?
It doesn't help it one bit
> that XML is optional. Pylons wasn't about being a kitchen sink of a
> framework - it was about being small and lightweight.
Pylons is about modularity and choice. Paste is the ultimate modular
foundation, and it needed a full-sized framework in the same spirit --
Pylons filled that role. That's what originally attracted me to
Pylons: it was written from the ground up based on the then-new Paste
and WSGI principles. Modularity => interoperability, the opposite of
vendor lock-in that previous frameworks had. The BFG architecture
allows Pylons to be a quantum leap more modular than it was before,
allowing Pylons to realize its original vision even further. If BFG
had existed in 2005 in its current form, there's a good chance that
Ben and James (Gardner) would have based Pylons on it from the
beginning. Especially if they had foreseen the dead-end features
Pylons made in 0.95 and 0.96, which it then had to backtrack from.
> Web framework in 2010 is supposed to do this:
>
> resources("cars") # <--- see there? that one line was supposed to give
> me /cars and /car/id for GET, PUT, UPDATE and DELETE requests,
> complete with views and default controller actions.
Routes already has this: ``map.resource("cars", "car")``. Ben is
currently adding all Routes features to Pyramid. He says that this
gives the chance to greatly simplify (shrink) the code, and to
refactor its internal structure based on the long-planned "Routes 2"
branch. So there will probably be some kind of
``config.add_resource_hander`` method for this.
Also, Routes recently added a submapper feature, so you can define
routes with common attributes in a "with" stanza, or add a group of
sub-URLs in one step (e.g., to drop in a generic package like a blog
engine). This has promise to simplify route maps, and could have made
past usages easier. So there's a strong inclination to reorient
Pyramid's routing in this way, and that may lead to a new way to
manage resource routes.
> Another thing web frameworks are supposed to do in 2010 is to define
> an HTML form which DOES NOT need to be parsed on the server and pre-
> populated with dictionaries of values to display a validation error.
I think this means, "Pylons/Pyramid should have a client-side
Javascript validator." This can be implemented with an add-on package
or enhanced application template. It would be a good job for
TurboGears. But there should not be one blessed Javascript library as
a mandatory dependency. We made that mistake in WebHelpers before. The
state of the art in Javascript libraries changes every six months, and
one library is better for some applications, and another library for
other applications.
Enhancements like these need to be made in separate packages so that
several implementations can be evaluated side by side. Then later, if
one is far superior to the others and is useful enough to justify
making it a mandatory dependency (meaning those who don't use it would
have to carry it around), Pyramid can add it.
> Also, a new web framework in 2010 should not be re-inventing Request
> and Response objects. What was wrong with Paste?! In 2 years reading
> Pylons-Discuss I have never once (!) seen any complaints about WebOb.
> Why is Pyramid brings yet another variant of response/request?!?
Pyramid has trivial subclasses of webob.Request/Response, just like
Pylons does or did. to add a few attributes or for backward
compatibility with older request objects.
> I guess you will use that [missing Rails-3 features] as an excuse to throw away
> Pyramid and launch Pyramid-2 based on something entirely different 2
> years down the road.
The state of the art always changes. Who can predict what will be a
best-practice in two years? Or what new paradigms or tools will
emerge. Maybe Pyramid can just add a couple features, or maybe it'll
need restructuring, or maybe it can be done on top of Pyramid without
affecting the base code.
> Also, if "stacked proxy globals" were such a big problem, why still
> have them? When I saw "configurator.start()" I immediately could smell
> something fishy. Just the fact that you have "doer" classes ending
> with "or" and having methods like "start" and "stop" tells a lot. This
> may not be that bad, but not SPECTACULAR, and spectacular is what you
> needed to justify killing of Pylons. Pylons was __amazing__, it just
> needed a better form handling package.
I don't like them either. It's a deprecated backward-compatibility
feature for old BFG apps, as it says clearly in the manual. But it's
not worth rejecting the codebase over one minor flaw.
ChrisM, can we just delete the threadlocal code now? Pyramid is a new
framework; it doesn't have to support all the old misfeatures in BFG's
history. Like Python 2 -> 3, and Pylons 0.9.7 -> 1.0. I also was
turned off by the threadlocals: it's something we wanted to get away
from in Pylons 2. It's not the "start" and "stop" methods that's the
problem, but the fact that users don't know how much overhead the
threadlocal code is causing in terms of CPU cycles or lines of code
(for space-constrained deployments like embedded systems and GAE).
Even if it's isolated in an unused module, it feels like the kind of
cruft we're trying to leave behind in Pylons 2.
On the other hand, some applications need thread locals for their own
purposes; e.g., for database connections. So if it can be implemented
and/or documented as a general thread local mechanism, rather than as
singleton/magic variables, that would deflect these criticisms.
By the way, Pylons users also need an upgrade path for 'app_globals'.
> I suspect quite a few Pylons folks will be unhappy.
There will always be somebody dissatisfied no matter what we do.
> We already saw (!)
> Repoze when we were picking our framework. And we didn't like it. We
> preferred Pylons. See, we already voted!
You saw Repoze before choosing Pylons. Repoze didn't exist when I
chose Pylons. (Or at least, BFG wasn't mature enough to be even known
to most WSGI users and developers.) I agree that we chose Pylons
because it didn't have XML or decorators. But now the time has come to
revisit that opposition, to see if maybe a small amount of them is
acceptable for the sake of a greater good.
By the way, you can write view methods without decorators or dict return values:
from ??? import render, render_template_to_response
c = self.request.tmpl_context # Or something like that
c.myvariable = "myvalue"
return Response(render("/index.mako"))
# - OR -
return render_template_to_response("/index.mako")
I don't remember the exact syntax of the render functions, but it's
similar to that.
The Pyramid docs recommend the decorators and dict return values for
most users, because we think it's a better way going forward (and that
TurboGears was right about that), but you can do it in a more
Pylons-like way as above if you want. This will be mentioned in the
final manual and howtos.
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> > Also, if "stacked proxy globals" were such a big problem, why still
> > have them? When I saw "configurator.start()" I immediately could smell
> > something fishy. Just the fact that you have "doer" classes ending
> > with "or" and having methods like "start" and "stop" tells a lot. This
> > may not be that bad, but not SPECTACULAR, and spectacular is what you
> > needed to justify killing of Pylons. Pylons was __amazing__, it just
> > needed a better form handling package.
>
> I don't like them either. It's a deprecated backward-compatibility
> feature for old BFG apps, as it says clearly in the manual. But it's
> not worth rejecting the codebase over one minor flaw.
>
> ChrisM, can we just delete the threadlocal code now? Pyramid is a new
> framework; it doesn't have to support all the old misfeatures in BFG's
> history. Like Python 2 -> 3, and Pylons 0.9.7 -> 1.0. I also was
> turned off by the threadlocals: it's something we wanted to get away
> from in Pylons 2. It's not the "start" and "stop" methods that's the
> problem, but the fact that users don't know how much overhead the
> threadlocal code is causing in terms of CPU cycles or lines of code
> (for space-constrained deployments like embedded systems and GAE).
I don't think CPU cycles are as much of a concern as other issues (the
overhead required to push and pop the threadlocal stack is minimal).
The real issue is the tension between wanting thread local variables and
not having them. In particular, being able to obtain the request as a
thread local is terribly handy on occasion. I'm on the fence about it
myself.
The begin()/end() pair during configuration is a convenient punching bag
for people who aren't going to use the system anyway, even if it made
toast for them. While I think it's reasonable to get rid of that
misfeature soon for "normal" configuration, I'm almost tempted to keep
it just out of spite. ;-) (joking, but not really).
In the meantime, it's very useful for BFG people to have one Pyramid
release that is backwards compatible with a BFG release, or at least to
which BFG apps can be ported in an automated fashion. I'll ask that we
get at least one release like that out before making any
BFG-incompatible changes.
> Even if it's isolated in an unused module, it feels like the kind of
> cruft we're trying to leave behind in Pylons 2.
>
> On the other hand, some applications need thread locals for their own
> purposes; e.g., for database connections. So if it can be implemented
> and/or documented as a general thread local mechanism, rather than as
> singleton/magic variables, that would deflect these criticisms.
In order to get a thread local managed by Pyramid, you have to call a
function:
from pyramid.threadlocal import get_request
request = get_request()
This differs from Pylons (and Flask) inasmuch as those two systems allow
you to do "from foo import athreadlocalvariable" (the purpose of a
"stacked object proxy"). I think this particular spelling is
problematic, because programmers tend to want to put imports outside the
scope of functions; the get_request() spelling on the other hand, while
it does use a thread local, causes no such desire. It's a "plain old
thread local" (if there is such a thing).
- C
Ev Kontsevoy
Pylons is that it has been the closest to "Rails in Python" thing we
had. You can call me "too pragmatic" perhaps, but I really wanted to
have an opinionated framework, with "one right way to do it" applied
to everything, including URL-to-code mapping. Rails-3 has brought an
amazing routing mechanism and I simply wanted for Pylons to follow the
lead. I believe that having many options are bad: XML? YAML? Why? Just
make one component (Routes) awesome enough to scratch an itch of 80%
projects with __minimal__ learning/coding effort.
> No previous framework has provided built-in primitives for all the programming styles that have emerged among the various post-2005 frameworks (traversal vs URL dispatch, "return render" vs decorators, class-based controllers vs a tiny function-based app that can fit in one module, etc). That was the original goal of Pypes. Pyramid's multiple modes allow almost any Python-WSGI framework to be built on top of it, which could provide a new level of unification among frameworks.
to get started using it. If that was the original goal of Pypes/Marco/
Pipefitters it should have been called Pypes or something else, I am
just sad that this thing has eaten my favorite framework :))
> The component architecture allows applications and the framework to be extensible in ways that weren't previously possible. Can you at least accept the possibility that *maybe* all these developers know something you don't
smart designs and the code is neat. It is a certainty, however, that
it's not what I need for my projects hence I can't call it "Pylons 2".
With the release of Rails-3 it has fallen behind in terms of speed of
development and ease of use. Pyramid is substantially lower level, and
seems like its done on purpose because you're suggesting other
frameworks to be built on top of it. But again, I wanted Pylons to
follow Rails, i.e. be more opinionated, offer more powerful routes,
require eve less code for typical CRUD, have powerful default RESTful
routes and controller/view defaults, etc...
> Can you attend PyCon next March in Atlanta? Then we can discuss the advantages and disadvantages of Pyramid in person with all the developers together. There will surely be Pyramid open spaces and a sprint, and we can even have some kind of "Is Pyramid good or bad for Pylons?" open space if there's enough interest. Again, your concerns are the same ones the Pylons developers raised with ChrisM two years ago. "Ewww, XML! Zope = bloat."
can be built on top of Pyramid.
> XML is a tool. It's ugly but it can do some things better than other
tools. I'm sure it's possible to create a YAML-based or Python-based
alternative to ZCML, because it all has to be converted to Python
objects in the end. But somebody would have to take that on as a
project.
exchange between systems written by different vendors. That's pretty
much the only use case I can think of (or ever could). Having the
option of ZCML is really just a dead weight because Python itself is a
much, much better tool to create "Python objects in the end". :)
> The only area where Pylons needed help... FOR YOU. Other people have different needs, such as making Pylons apps more nestable, getting away from the magic globals, making apps more plugin-friendly.
has been the most popular topic to bitch about (in my opinion) on
pylons-discuss, while nobody ever complained about magic globals or
plugins. Also, just to make a dent, I want to vote *for* magic globals
one more time! :) pylons.config and others have been awesome for us,
we learned when not to use it and love it when we can.
> Routes already has this: ``map.resource("cars", "car")``. Ben is currently adding all Routes features to Pyramid. He says that this gives the chance to greatly simplify (shrink) the code, and to refactor its internal structure based on the long-planned "Routes 2" branch. So there will probably be some kind of ``config.add_resource_hander`` method for this.
for Python" it is clear to me now that its authors never had such goal
in mind. With that said, I want to thank all of you guys for putting
your brains in time into these projects, there's so many quality
Python components out there, that it's not hard to assemble a very
Rails-like custom setup by hand.
Also, Mike, thanks for spending so much time answering my questions
and addressing my frustrations. This wasn't the first time this group
blows my mind with the quality of posts from regular contributors.
Mike Orr
> In order to get a thread local managed by Pyramid, you have to call a
> function:
>
> from pyramid.threadlocal import get_request
> request = get_request()
>
> This differs from Pylons (and Flask) inasmuch as those two systems allow
> you to do "from foo import athreadlocalvariable" (the purpose of a
> "stacked object proxy").
I should add that I've long advocated the function syntax for Pylons.
Quixote uses it, and it says clearly, "This function is doing
something." It also provides an obvious place for the code that
fetches the object. A plain ol' module attribute doesn't have a place
for that code, which is wny one has to embed it in a proxy. But
proxies can't emulate the object completely. Doing "dir(request)" in
Pylons in Pylons won't show you the interesting request attributes and
method names; it'll show you the proxy's attributes. You have to do
the little-known "dir(request._current_obj())" to see the request
methods.
Chris, I'm sure you're aware that the SOPs are not just thread locals.
They're thread-and-application-instance locals, in case you have
multiple Pylons apps (or multiple instances of the same Pylons app)
running in the same process. Because each application has its own
'app_globals' and 'config'. How do Pyramid's threadlocals handle
multiple applications, or do they?
--
Mike Orr <slugg...@gmail.com>
Mike Orr
On Sun, Nov 7, 2010 at 9:28 AM, Ev Kontsevoy <eug...@gmail.com> wrote:
>> No previous framework has provided built-in primitives for all the programming styles that have emerged among the various post-2005 frameworks (traversal vs
>
> I understand. The issue is that soon we'll need a "Bible of Pyramid"
> to get started using it.
The Pyramid book already feels bible-like. I wish there was a manual
as extensive without the BFGisms which distract/confuse Pylons users,
but it's what we have. And it's much more extensive documentation than
Pylons ever had. It was going to be an immense project to integrate
all the dependency docs into the Pylons manual, but adopting BFG and
its book obviates the need for all that.
> I am
> just sad that this thing has eaten my favorite framework :))
Nice metaphor. But it's like Python 2 -> 3. If people are majorly
dissatisfied with Pyramid, they can continue using and helping to
develop Pylons 1. A separate "Pylons 2" is possible if somebody
outlines the goals for it and convinces the rest of us of the need for
it. Perhaps another team can take over Pylons development at that
point, the way Ian handed SQLObject maintenance to Oleg when he
switched to SQLAlchemy.
> I wanted Pylons to
> follow Rails, i.e. be more opinionated, offer more powerful routes,
> require eve less code for typical CRUD, have powerful default RESTful
> routes and controller/view defaults, etc...
After years of requests for alternate APIs by users, and a few users
subclassing PylonsApp, and our own discovered needs as we built apps,
we generally came to the conclusion that Pylons was a bit too rigid.
Just a bit, mind you. We can still keep the opinionated vision in the
docs, while providing more hooks in Pylons for alternatives. Pyramid
adds those hooks. Those mandatory dependencies (FormEncode,
WebHelpers) are a nuisance if you're not using them, and a practical
problem in space-challenged deployments (Google App Engine).
The framework you want can be built on top of Pyramid. Maybe
TurboGears 3 will be it , or maybe a new framework. If Pyramid has
inefficiencies (excess overhead), this may be a problem. But first we
have to identify what the overhead is and whether it actually exists.
Unused ZCML parsers and threadlocal modules are insignificant in this
regard. If they are always active and draining CPU cycles and
burgeoning call-stack levels, then we can address those problems
directly.
(Note: the BFG/Zope dependencies are of course numerous compared to
Pylons, and that will be an intrinsic issue for space-challenged
deployments. But most users are not running on platforms where it
matters. I also mentioned Pylons' unexpectedly-high memory usage, and
how it does best on 1 GB servers. I don't know how Pyramid compares in
this regard, whether it's more frugal or prodigal. That's another
issue to focus on someday.)
BTW, there is an ambiguity between Pyramid the meta-framework, and
Pyramid the top-level framework (Pylons style or BFG style). I wish
these had remained distinct in the branding, with the meta-framework
under one name and in a separate package, and the top-level framework
with its own name. But others felt differently about this, that
Pyramid should simultaneously be a complete Pylons-style framework,
and a meta-framework (like Paste). That it would be easier to market a
single framework than a dichotomy.
>> XML is a tool. It's ugly but it can do some things better than other
> tools.
>
> XML is a tool for data
> exchange between systems written by different vendors.
That is one of its unique strengths, that the widest variety of
programmers have XML experience and tools. Another is marked-up text.
There's XHTML, but YAML/HTML or JSON/HTML would be ridiculous and
unreadable. But XML has its downsides, which is why JSON and YAML have
become popular.
Re Python configuration format, I have worked with several frameworks
and programs that have a variety of configuration formats: Python,
INI, XML, CSV, etc. There are three general Python formats: simple
variable assignments in a module, nested dicts in a module, and
classes-attributes-subclasses in a module. All of these are limited in
different ways. The simple variable-assignment approach doesn't have
sections (unless you use a custom preprocessor), and it supports
nesting only in the sense that objects can contain objects, not at the
top level. The syntax can be overly verbose for a config file,
depending on the target data types. It presents a barrier if the app
maintainer is not familiar with Python syntax rules. (He may be a
generic sysadmin.)
The nested dict approach is rather ugly and has too many "{" and "}".
The first line is a single "{", which is rather useless for the human
maintainer.
The class-attribute-subclass approach is overly verbose due to the
"class" keyword. Some systems use a preprocessor to add it in, but
then you've strayed from the simple "execfile()" model.
Python format can be a security vulnerability if you don't trust the
user, because there is no effective way to ban imports or
introspection tricks in Python. The right attribute-subattribute
incantations can let you access everything. The user can also
accidentally cause the program to malfunction if he gets too elaborate
with imports and assignments, which is then a tech-support headache.
So Python format has its advantages and disadvantages, but it's not
always superior in every situation. There were debates in TurboGears
and Pylons and Pypes which format to use, and they went back and forth
several times before deciding to adopt the Paste INI format.
> Let me disagree. I simply observed the fact that dealing with forms
> has been the most popular topic to bitch about (in my opinion) on
> pylons-discuss, while nobody ever complained about magic globals or
> plugins.
People have complained about it all over the place, as they want to be
reassured their application won't blow up or misbehave in some edge
case. And the second-most popular bitch topic after forms is Auth
systems, the lack of it in Pylons, and the controversial AuthKit which
is recommended in the Pylons book.
> Also, just to make a dent, I want to vote *for* magic globals
> one more time! :)
Noted. But be aware that they will intentionally not be implemented in
Pyramid. You can mount a Pylons app in Pyramid that uses magic
globals, or wait for a higher-level framework that has them.
>> Routes already has this: ``map.resource("cars", "car")``. Ben is currently adding all Routes features to Pyramid. He says that this gives the chance to greatly simplify (shrink) the code, and to refactor its internal structure based on the long-planned "Routes 2" branch. So there will probably be some kind of ``config.add_resource_hander`` method for this.
>
> That's great news! Thanks.
I should have said, "paster restcontroller" is what gives you the
controller corresponding to a resource route. I don't think Pyramid
has this yet but it should. (At least, the pre-Pyramid code I tried
recently didn't have it.)
> Also, Mike, thanks for spending so much time answering my questions
> and addressing my frustrations. This wasn't the first time this group
> blows my mind with the quality of posts from regular contributors.
Thanks. :) As I said in the Rails thread, this is a personal goal of
mine, to keep the Pylons lists friendly and inclusive, and to not
shout at newbies when they don't RTFM or don't understand it.
--
Mike Orr <slugg...@gmail.com>
Tim Black
plan Pylons and TurboGears had a while back where Pylons would be the
"lower-level" or basic framework and TurboGears would be the "Full
Stack" framework with sensible/opinionated defaults, this whole
discussion is making me think it might be a good idea to make the front
page of the final website for Pyramids present something like this:
3 buttons:
1. Get "Bare Metal" Pyramids ( => Pylons) | 2. Get "Full Stack"
Pyramids ( => TurboGears)
3. Or get other Pyramids mixes/distributions ( =>
third-party/community frameworks based on Pyramids)
Or make the Pyramids site say:
Get Pyramids | Need more? Get TurboGears
And make the TurboGears site say:
Get TurboGears | Need less? Get Pyramids
It seems to me this sort of clear set of recommended options for which
framework to choose would help answer concerns like Ev's above from the
outset.
Tim
Christoph Zwerschke
> Get Pyramids | Need more? Get TurboGears
The "more/less" dichotomy may be somewhat misleading, though. The top
layers will certainly add features and functionality, but on the other
hand they will also hide some of the lower-level features and
complexity, e.g. by providing object tree dispatch so you don't need to
deal with manual dispatch rules and contexts. In this sense, people want
to choose the higher-level layer because they actually want less (of the
lower-level complexity), not more. Letting the top layer provide
reasonable opinonated defaults is also because people normally want to
have less (decisions to make), not more.
-- Christoph
Mike Orr
Still, the idea of the catchy links is good. We could have a "What's
the difference?" link next to it.
Perhaps TurboGears can be renamed to show a closer relationship to
Pyramid, without being "THE (one and only) high-level Pyramid
framework". Perhaps a "Pyramid with Batteries" kind of something. Ben
had suggested Gears, but I said Google may have trademark objections
about that. But maybe "Pyramid Gears" as a full name would work.
--
Mike Orr <slugg...@gmail.com>
Christoph Zwerschke
> Still, the idea of the catchy links is good. We could have a "What's
> the difference?" link next to it.
I think the barebone Pyramid should be labelled something like "core" or
"base". Most people would understand what that means. Not sure what
would be the right catchy label for the high-level stuff then.
> Perhaps TurboGears can be renamed to show a closer relationship to
> Pyramid, without being "THE (one and only) high-level Pyramid
> framework". Perhaps a "Pyramid with Batteries" kind of something. Ben
> had suggested Gears, but I said Google may have trademark objections
> about that. But maybe "Pyramid Gears" as a full name would work.
We are currently brainstorming the name for TG 3 in the TurboGears devel
team. I'll throw that in.
-- Christoph
Andrew Sawyers
http://www.wunderground.com/cgi-bin/findweather/getForecast?query=98584&hour
ly=1&yday=314&weekday=Thursday
Tim Black
comes along and sees the word "more," they might think, well, I don't
want more work, I want the easiest set of defaults to start with, and
they would end up picking Pyramid when they probably really wanted
TurboGears. So the words "more" and "less" probably aren't the clearest
way to give people initial advice about which framework to pick. But I
think some simple presentation of two recommended options would be a
good idea.
Maybe we can find some other simple terminology that will express the
difference clearly. Iif the terminology went into the frameworks'
names, maybe they could be "Pyramid Core" and "Pyramid Full-Stack."
"Pyramid Core" is fairly clear, but "Pyramid Full-Stack" might not be
clear to someone who doesn't know web frameworks, and maybe isn't even
accurate, if "Pyramid Core" qualifies as a full-stack of sorts.
"Pyramid with Batteries" might work, but fails to indicate that it
provides recommended defaults that simplify your work. "Turbo"
expresses the latter idea well, and "Gears" expresses the "batteries
included" idea, so maybe "TurboGears" is a good name to retain. Or
maybe there's an architectural term that would be suitable--"Pyramid
Base" and "Pyramid Peak." Um...Pyramids on Rails? But the pyramids are
from the ancient world, and from Egypt, and trains are from the
industrialized 1800's. Some other ideas: "Pyramid Focal," "Point,"
"Keystone," "Apex." "Hyper Pyramid?"
Or the distinction could be kept out of the name (who wants to change
their favorite framework's name?) and just expressed in adjectives or
comparatives: "more/less," "basic/extended," etc. But then, I suppose
it's wise to consider that comparisons are the stuff of flame wars. But
I think there's some hope that presenting a well-conceived and
well-expressed distinction up front could head off some of those flame
wars from the outset.
Tim
Andrew Sawyers
Sorry for the noise, I'm a numpty. Forgive me.
Cheers,
Andrew
Chris McDonough
things with Pyramid (like a theoretical TurboGears 3).
There's one camp of people who just want different defaults (a different
traverser, a different templating language, a different source code
layout, etc). But they don't really want to build an *application*,
they want to configure Pyramid as a slightly different framework more to
their tastes.
There's another camp that wants higher-level application features,
something that, when you run it, shows something useful in a browser.
Such a thing might require dependencies on SQLAlchemy, or Mongo, a
dependency on a particular form framework. It might create a default
"admin" interface, or a small content management system, or whatever.
But it'd have an *application* component, not just different frameworky
defaults.
It'd be a good idea for the folks in each of these camps (to the extent
that you're not in both) to try to work out exactly what it is they
want, and perhaps split into two teams. One might build on the others'
work, or might not.
Personally, I'm in the "application features" camp. I don't really want
different defaults, or more frameworky bits for the sake of distinction
That's easy for me to say, because the defaults already suit me, I
understand why you might want others though. But I'd rather have a
higher level thing built directly on Pyramid that "puts pixels on the
screen" out of the box. Such a goal might require the creation of a
bunch of related frameworks, but the frameworks would be developed with
the goal in mind of creating a "pixels on the screen" end user
application that someone could run and get benefit from without doing
any heavy development.
(By the way, it's "Pyramid", not sure how the pluralization crept in.)
- C
Christoph Zwerschke
> I agree fully on this, and I can see that if someone new to Pyramid
> comes along and sees the word "more," they might think, well, I don't
> want more work, I want the easiest set of defaults to start with, and
> they would end up picking Pyramid when they probably really wanted
> TurboGears.
That's exactly what I meant. In case of doubt, it will be better if
people start with the high-level stuff so they will not be disappointed
because of the low-level complexity or missing high-level features.
> Some other ideas: "Pyramid Focal," "Point," "Keystone," "Apex."
> "Hyper Pyramid?"
I like "Point". The Hyper pyramid would be a Pentachoron. Both go well
with the "P" theme of Pylons and Pyramid.
Apex is already taken by Oracle.
-- Christoph
blaf
level stuff and the site must provide that information unambiguously;
by words, by content organization, by layout, etc...
We also need to make a distinction between projects developed by The
Pylons Project and by third parties, not to create confusion and have
a cohesive collection.
I think Pyramid must be associated with something like a «core» or a
«base» framework and it's why we must not use a name including Pyramid
for an higher-level framework based on it, it's just too confusing. A
plugin or extension like pyramid_beaker makes sense because it plugs
another lib to extend the core framework, but «gears» will define
policies, rules and opinions so it needs to be self defined. Pyramid
is not called Paste Pyramid or WebOb Pyramid because it uses them to
provide functionalities.
It's not an easy task...
Blaise
John_Nowlan
And I'm in the application camp (RIA?)
https://groups.google.com/group/turbogears/msg/c7ca544cd4f19550?hl=en
(asking about tg plans to occupy the pyramid 'application' space)
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-
> discuss+u...@googlegroups.com.
Christoph Zwerschke
> Personally, I'm in the "application features" camp. I don't really
> want different defaults, or more frameworky bits for the sake of
> distinction
I'm with you on that. And by "application" I don't mean bare html web
forms, but attractive RIAs with Javascript GUIs. The high level layer
should really be an alternative to people who would otherwise use Google
Web Toolkit.
> (By the way, it's "Pyramid", not sure how the pluralization crept in.)
Maybe confusion because Pylons is plural.
-- Christoph
Mike Orr
I think Ben has his heart set on the name Pyramid for the
Pylons-level framework, and is already making website design and
marking plans based on that. So the high-level framework can be called
TurboGears or something closer to Pyramid, but not Pyramid itself.
However, there have long been requests for a batteries-included form
of Pylons. We have always referred people to TurboGears for that. But
with the merger (if TG agrees to join it), a tighter branding may be
more appropriate, like Pyramid Gears. That way there's an "official"
high-level framework, clearly integrated and not just stuck onto it
like a Christmas tree ornament, and then we'll look like a
full-service organization (good for marketing). But I don't want to
preclude other high-level frameworks with semi-affiliated status.
There are too many legitimate alternatives to exclude them, and the
Python-web landscape would be more unified and interoperable if more
of the frameworks were built on the Pyramid stack.
"Paste Pyramid" and "WebOb Pyramid" are not really along the same
lines. Paste and WebOb are low-level utilities, while Pyramid is a
complete framework. Pyramid : PyramidGears is more like Debian :
Ubuntu, not GNU : "GNU/Linux" : Debian.
--
Mike Orr <slugg...@gmail.com>
Marius Gedminas
> (By the way, it's "Pyramid", not sure how the pluralization crept in.)
Pylons was plural, and also started with a P.
Marius Gedminas
--
Never reinvent the wheel unless you really need a square one. :^)
-- Duncan Booth
blaf
On Nov 9, 5:21 pm, Mike Orr <sluggos...@gmail.com> wrote:
> "Paste Pyramid" and "WebOb Pyramid" are not really along the same
> lines. Paste and WebOb are low-level utilities, while Pyramid is a
> complete framework. Pyramid : PyramidGears is more like Debian :
> Ubuntu, not GNU : "GNU/Linux" : Debian.
an higher-level system based on Debian, it wasn't named Debian Ubuntu.
On the other hand I think the Pylons Project higher-level framework
based on Pyramid should share the same thematic as Pylons and
Pyramid :)
Blaise
Tim Black
> I think Ben has his heart set on the name Pyramid for the
> Pylons-level framework, and is already making website design and
> marking plans based on that. So the high-level framework can be called
> TurboGears or something closer to Pyramid, but not Pyramid itself.
>
> However, there have long been requests for a batteries-included form
> of Pylons. We have always referred people to TurboGears for that. But
> with the merger (if TG agrees to join it), a tighter branding may be
> more appropriate, like Pyramid Gears. That way there's an "official"
> high-level framework, clearly integrated and not just stuck onto it
> like a Christmas tree ornament, and then we'll look like a
> full-service organization (good for marketing). But I don't want to
> preclude other high-level frameworks with semi-affiliated status.
> There are too many legitimate alternatives to exclude them, and the
> Python-web landscape would be more unified and interoperable if more
> of the frameworks were built on the Pyramid stack.
>
> "Paste Pyramid" and "WebOb Pyramid" are not really along the same
> lines. Paste and WebOb are low-level utilities, while Pyramid is a
> complete framework. Pyramid : PyramidGears is more like Debian :
> Ubuntu, not GNU : "GNU/Linux" : Debian.
Pyramid : TurboPyramid
That's perfect. It keeps the Pyramid brand, it respects the fact that
TurboGears is the fast way to get started, and the TurboGears community
is likely to like it because it retains part of the TurboGears brand,
and represents the significant change of underlying components from
(CherryPy -> ) Pylons -> Pyramid. It's still TurboGears, but has
Pyramid running under the hood.
Tim
Chris McDonough
But is TurboGears the fast way to get started? I ask this because
currently TurboGears doesn't include any OOTB application functionality
in its core. It provides a bunch of frameworky bits that someone can
glue together if they work hard to make an application. It has some
batteries but the batteries are still extremely low-level.
However, it's already pretty fast to get started in this same way using
plain-Pyramid. What will a nascent TurboPyramid offer above what
Pyramid does now?
Does TurboGears/TurboPyramid want to be a "best of breed framework"
still or does it want to have application components?
If it wants to have application components (like an admin UI, perhaps a
blogging tool, a user registration system), etc, I'd say "yes,
TurboPyramid is a fast way to get started". If not, I think it's just a
different way to get started. While having a different way to get
started would be fine, and TurboPyramid is not a horrible name for that,
it's unlikely I'd personally be helping on that effort unless it puts
some "pixels on the screen" in the form of application functionality.
- C
Mike Orr
>> That's perfect. It keeps the Pyramid brand, it respects the fact that
>> TurboGears is the fast way to get started,
>
> But is TurboGears the fast way to get started? I ask this because
> currently TurboGears doesn't include any OOTB application functionality
> in its core. It provides a bunch of frameworky bits that someone can
> glue together if they work hard to make an application. It has some
> batteries but the batteries are still extremely low-level.
Haha, I've never heard TurboGears described as "low level".
There are really two kinds of users, with different notions of what "a
fast way to get started" is. One wants only the essentials and a short
manual. The other wants all the optional parts prechosen and
preconfigured. The third option, with application components, is
something TG and Pylons have never really addressed, although TG has
had db-admin and I think general admin screens at various times (until
they become obsolete and don't get replaced). I guess Django has more
of the application components, and that's one reason so many people
have been using Django.
But certainly there's a need for a TurboGears-level framework in any
case. Many people don't want to spend hours deciding which auth
library or form library or Javascript library to use, and they want
admin screens and create-an-account-with-email-confirmation screens
out of the box. But things like blogs and registration systems are a
little big; they will always be add-on components. (Unless you're
Zope.)
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> On Tue, Nov 9, 2010 at 3:10 PM, Chris McDonough <chr...@plope.com> wrote:
> >> That's perfect. It keeps the Pyramid brand, it respects the fact that
> >> TurboGears is the fast way to get started,
> >
> > But is TurboGears the fast way to get started? I ask this because
> > currently TurboGears doesn't include any OOTB application functionality
> > in its core. It provides a bunch of frameworky bits that someone can
> > glue together if they work hard to make an application. It has some
> > batteries but the batteries are still extremely low-level.
>
> Haha, I've never heard TurboGears described as "low level".
Well, lower level than an application anyway. Lower level than Django,
even.
> There are really two kinds of users, with different notions of what "a
> fast way to get started" is. One wants only the essentials and a short
> manual. The other wants all the optional parts prechosen and
> preconfigured. The third option, with application components, is
> something TG and Pylons have never really addressed, although TG has
> had db-admin and I think general admin screens at various times (until
> they become obsolete and don't get replaced). I guess Django has more
> of the application components, and that's one reason so many people
> have been using Django.
>
> But certainly there's a need for a TurboGears-level framework in any
> case. Many people don't want to spend hours deciding which auth
> library or form library or Javascript library to use, and they want
> admin screens and create-an-account-with-email-confirmation screens
> out of the box. But things like blogs and registration systems are a
> little big; they will always be add-on components. (Unless you're
> Zope.)
But as far as I can tell, TurboGears 2 doesn't have any of the things
you mention above *working* of-the-box as core functionality.
It does depend on SQLAlchemy, and there is some information about how to
use SQLAlchemy in its docs. Its docs also show you how to use
ToscaWidgets, but it doesn't have any forms configured in its
quickstart. So it makes choices about a form library and a persistence
system, but only as dependencies. I *think* this is because its users
want it to be flexible, like a lower-level framework might be, which is
where I get confused.
It depends on Sprox, but there's nothing in the TG2 docs that tell you
how to use Sprox. Likewise with Catwalk. There is an admin interface
add-on to TurboGears 2
(http://www.turbogears.org/2.0/docs/toc.html#tg2-extensions) that uses
Sprox, but it's not included in the core. Its core docs do not tell you
how to use any particular JavaScript library in a TG2-specific way.
So as far as what's documented as useful out of the box, TurboGears 2
itself doesn't provide *that* much more than a Pyramid paster template
like "plylons_sqla" does right now. You can cobble together enough
information to understand how to use all of its dependencies, but that'd
be true of using them with Pyramid as well.
Do you see the distinction?
- C
Mike Orr
I thought these things were preconfigured in TG, or at least available
in optional application templates. If not, this would be a good thing
to add. Or maybe the TG developers can clarify the goals of the
framework, and whether they might want to go to a higher level in TG3.
--
Mike Orr <slugg...@gmail.com>
Tim Black
not trying to be a CMS; rather, it's the pieces out of which someone
could build a CMS if they want.
That said, the TurboGears admin interface DOES work out-of-the-box:
"The TurboGears Admin comes configured out-of-the-box for use with the
default quickstarted template model."
See
http://www.turbogears.org/2.1/docs/main/Extensions/Admin/index.html#using-adminconfig,
which includes a screenshot. The admin interface is a model browser,
which of course would not be a complete CMS admin interface.
So this isn't quite true:
> It provides a bunch of frameworky bits that someone can
> glue together if they work hard to make an application. It has some
> batteries but the batteries are still extremely low-level.
...because TurboGears does glue the frameworky bits into a working
application that actually displays in the browser, though that
application doesn't do much compared to the applications it expects you
to create out of that foundation.
> However, it's already pretty fast to get started in this same way using
> plain-Pyramid. What will a nascent TurboPyramid offer above what
> Pyramid does now?
>
> Does TurboGears/TurboPyramid want to be a "best of breed framework"
> still or does it want to have application components?
I think those questions are best left to be answered by Mark Ramm and
others who are its core developers.
> If it wants to have application components (like an admin UI, perhaps a
> blogging tool, a user registration system), etc, I'd say "yes,
> TurboPyramid is a fast way to get started". If not, I think it's just a
> different way to get started. While having a different way to get
> started would be fine, and TurboPyramid is not a horrible name for that,
> it's unlikely I'd personally be helping on that effort unless it puts
> some "pixels on the screen" in the form of application functionality.
Although I'm sure this will not be seen as a good idea by some (because
it might prejudice TurboGears toward blog functionality), maybe to help
satisfy your concern, to encourage people to adopt TurboGears (because
many sites/clients want a blog page somewhere as a core feature), and to
give a good example of how to begin extending the quickstart template,
TurboGears would be wise to make a very simple blog page
(model/controller/view set under a separate sub-controller class/object
in a Python egg that could be improved in the future--call it
tgext.blog) as a default page in the quickstart template. That way
people would see that in fact it is a working application--you can make
blog posts in the admin pages, and they show up on the frontend under
the "Blog" menu item.
I think it would be smart to package up TurboGears' wiki tutorial in a
similar fashion, and offer it as a discrete package included in the
quickstart, or as a package that is optional but easy to install.
Tim
Chris McDonough
> That said, the TurboGears admin interface DOES work out-of-the-box:
>
> "The TurboGears Admin comes configured out-of-the-box for use with the
> default quickstarted template model."
>
> See
> http://www.turbogears.org/2.1/docs/main/Extensions/Admin/index.html#using-adminconfig,
> which includes a screenshot. The admin interface is a model browser,
> which of course would not be a complete CMS admin interface.
When I followed the instructions at
http://www.turbogears.org/2.0/docs/main/DownloadInstall.html#manual-installation I wound up with a quickstarted project that has no mention of an AdminController. But sure enough, tgext.admin is indeed a dependency of tg.devtools, so it did get installed when I followed the core installation instructions, and presumably you'd just need to follow the instructions you link above to enable the admin. My bad, sorry.
- C
Tim Black
2.1 does. In 2.1, you can't see the "Admin" link until you log in; you
might try logging in.
Tim