Re: pyramids and pylons
On Sat, Nov 6, 2010 at 10:29 PM, cd34 mcd...@gmail.com wrote: On Nov 6, 1:46 pm, Jeff Tchang jeff.tch...@gmail.com wrote: As a long time user of Pylons the thing that scares me is migration. How much work is it going to take to get my Pylons 9.7/1.0 project to Pyramid. Also since I have projects currently being worked on in Pylons how much of this is going to be dead end work? http://cd34.com/blog/framework/pylons-1-0-to-pyramid-1-0a1/ I had an undeployed Pylons 1.0 project that we had started working on about three weeks ago. Thanks, cd34. I've added links to this in the Pyramid Supplemental Docs. http://bytebucket.org/sluggo/pyramid-docs/wiki/html/index.html (This site is a holding place for my documentation until we figure out what to put in the official docs, and also so that I can keep the source in its own repository.bytebucket.org is an automatic redirect from BitBucket; I guess that's how they serve static content.) It also contains the Pylons 1.0 Execution Analysis, which I submitted to the Pylons docs but I don't think it's there yet. -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramids and pylons
I'm glad to see (vis a vis this discussion thread) that the elephant in the room now has a bright light shining on it. As soon as I caught wind of repoze.bfg and now pyramid, I put a couple of hours into reading through the docs. To me it was apparent even at first look that the new ontology is more straightforward, and we will be able to put new apps together even more clearly and simply than ever. Nothing struck me as more complicated. All I see is more options and a very significant success in simplifying and clarifying the tasks that a developer has to go through to get his app or site up and running. I'm not surprised the news is shocking to some, but the new direction makes me very happy. I never really felt at ease with how much Pylons configuration was tucked away in multiple python files. Any time I took a break from Pylons for a few months, when I came back I invariably had to read through Mike's execution analysis to wrap my head around what was actually going on and why some configuration was here, some was over here, and some was in yet another place. Three cheers for Pyramid. Now how long before someone writes a build template for it and calls it Cheops or Khufu or some other famous pharaoh's name... - Eric On Nov 5, 3:10 pm, Ben Bangert b...@groovie.org wrote: On Nov 5, 2010, at 1:50 PM, Jens Hoffrichter wrote: Thanks to especially Graham and Mike to point out what the benefit for the end-user-developer (a crude term, I know ;) ) will be with the Pylons2/Pyramid move. When I started to read these posts, I was a bit concerned, too. I (we, my company) have been long time Pylons users, and admittedly, we have seen more changes in Pylons than we liked. I could understand the reasoning behind all those changes, still, for the developer they pose a hazard in long-term-evolution of a written app. Some of the things I mean: - The deprecation of rails-style webhelpers. We depend on those quite a bit in our first application we wrote (and which is still live) No worries, these are not dead! The WebHelpers package isn't going anywhere, and its still easy to use throughout your templates. - Change in how to address a template (from package.template to package/template.mak) Ah, sorry if that's confusing. The dotted notation for a full 'resource specification' is optional:http://docs.pylonshq.com/pyramid/dev/narr/views.html#mak-or-mako-mako... You can and do of course, configure Mako to have a template directory, and relative names like 'foo.mak' are assumed to exist in said template dir. The ability to use a full resource specification addresses a long-time noted issue with extending or re-using packages of your templates. While Mako lets you plugin multiple template paths, the overlap can get tricky to manage, being able to refer to a template with its package name is specifically to allow you to use templates that might be in another package for extending purposes. Consider the case where you have a set of templates you use in all your projects, wouldn't it be nice to have a package of those you just call into? And if you needed to tweak just one of those, you could override it with a template of your choice via the override API:http://docs.pylonshq.com/pyramid/dev/narr/resources.html#the-override... This is the start of where many frameworks are telling you to fork code ;) - The move from implicit routes to explicit routes Yes, all routes do have to be explicit. I was moving that way in Pylons 1.x with Routes already actually, as the implicit naming and resolving done in Routes generally leads to more problems for users, than helping. And if I thought a bit more, I would probably come up with a couple of more examples, which have been problematic for us. The problem in there is, that there normally is no smooth upgrade path, and no backwards compatibility, so we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, as no one would pay us a money for the complete rework the older apps need, as for the customer, it would mean very little benefit. I've tried to provide as smooth an upgrade path as possible between various versions of Pylons. From the upgrade path's I've seen in other web frameworks, its one of the smoother ones... but the fact that so much configuration was in Python files rather than the framework has been very problematic as extensive changes are needed for upgrades as half the 'framework' is more or less assembled in the project itself. pyramid does not have this issue, as rather than having all its configuration innards in your project, you configure pyramid via hook points. Don't get me wrong, I love pylons, and the first question we ask ourselves when a new project comes in is, Can we solve this in pylons, or do we have to implement it with something different?, but the lack of continuity has been a bit
Re: pyramids and pylons
On Sat, Nov 6, 2010 at 4:03 AM, Eric Ongerth ericonge...@gmail.com wrote: I'm glad to see (vis a vis this discussion thread) that the elephant in the room now has a bright light shining on it. As a Pylons user, I think one of the most important things that this discussion shows is that the core developers have direction, energy, and openness to making this framework better through collaboration. Its easy to take that for granted, but not every project has this. -- 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.
Re: pyramids and pylons
As a long time user of Pylons the thing that scares me is migration. How much work is it going to take to get my Pylons 9.7/1.0 project to Pyramid. Also since I have projects currently being worked on in Pylons how much of this is going to be dead end work? I am hoping that there will be specific migration patterns to ease this pain. A step by step guide for migration so I can at least understand what work will be required. What is the recommendation at this point for someone in the middle of creating a Pylons 9.7/1.0 app? My assumption is to continue but be aware that a year or two down the road to expect a rewrite. How about new projects? Should they immediately start using Pyramids and abandon Pylons? -Jeff -- 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.
Re: pyramids and pylons
Jeff, Pyramid allows you to mount an existing Pylons app and serve it right through without modification. Having done so, you are then free to convert the app page by page, or handler by handler or however you wish to proceed ... or leave it unchanged. Eric On Nov 6, 10:46 am, Jeff Tchang jeff.tch...@gmail.com wrote: As a long time user of Pylons the thing that scares me is migration. How much work is it going to take to get my Pylons 9.7/1.0 project to Pyramid. Also since I have projects currently being worked on in Pylons how much of this is going to be dead end work? I am hoping that there will be specific migration patterns to ease this pain. A step by step guide for migration so I can at least understand what work will be required. What is the recommendation at this point for someone in the middle of creating a Pylons 9.7/1.0 app? My assumption is to continue but be aware that a year or two down the road to expect a rewrite. How about new projects? Should they immediately start using Pyramids and abandon Pylons? -Jeff -- 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.
Re: pyramids and pylons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5 Nov 2010, at 15:05, Graham Higgins wrote: (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.) Okay, here's one, in the form of some profiling data: Pylons: http://svn.repoze.org/whatsitdoing/pylons/results.txt 256145 function calls in 0.811 CPU seconds bfg (~= Pyramid) http://svn.repoze.org/whatsitdoing/bfg/results.txt 20013 function calls in 0.084 CPU seconds Mmm. - -- Cheers, Graham http://bel-epa.com/gjh/ -BEGIN PGP SIGNATURE- iEYEARECAAYFAkzWEbMACgkQOsmLt1NhivzoowCfXo4GHcVF8lijXui7YDtsJvIa 1JMAn0x/aM9ByUT1PZZ4fvFDUS2bXlg7iQCVAgUBTNYRs1nrWVZ7aXD1AQKRbgP/ UOHgw//hOLXChjzkDdJJrTsVzqNhI4H4KOtruCc9m5KF/NR6BuFrSzu6ngkgRQ39 oHwf7KnY/ooF2JY6x1HGV9VJoUJhY/U841NqO2jxe/WrmjPeWxCME0z/WCI4n26z HylyqBUrCWOjoLNK0KqDTvW9wfwudcwsVAbFENSBeAo= =zy1G -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.
Re: pyramids and pylons
I've been following this discussion for the last couple of days, and I'm still a bit confused. I've just started playing with pylons. I downloaded the 1.0 code and started writing a toy application just to get the feel for it. If I were to embark on a real project today, would the right game plan be to continue with Pylons 1.0, or wait for Pyramids to come out (and/or stabilize?). Or just use Django? :-) I note that http://pylonshq.com/ doesn't mention Pyramids at all. -- Roy Smith r...@panix.com -- 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.
Re: pyramids and pylons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7 Nov 2010, at 02:40, Graham Higgins wrote: Pylons: http://svn.repoze.org/whatsitdoing/pylons/results.txt 256145 function calls in 0.811 CPU seconds Slight correction... That was Pylons 0.9.7 Chris informs me. Pylons 1.0 was whittled down to about 150K. Also, the standard caveat that those figures usually get drowned if the app is doing any serious work. This from Ben: The bare minimal execution stack during a 'hello world' request in pyramid is 20 function calls. In pylons, even with all the middleware stripped, its 256. I find it a useful datum - it means that I can feel comfortable serving /favicon.ico and /robots.txt, etc. directly from the app if I want. Some early reports of reasonable speedups (*2) after porting apps from Pylons/GAE to Pyramid/GAE, too early to start grinning yet. - -- Cheers, Graham http://bel-epa.com/gjh/ -BEGIN PGP SIGNATURE- iEYEARECAAYFAkzWG60ACgkQOsmLt1NhivzgmQCg/Y35WGe3xJZl7wDpqY1exVwD IHMAoKIZI/han2HgKO5KvFGEcDf60BkJiQCVAgUBTNYbrVnrWVZ7aXD1AQIFwwQA 4DhTKdmw+O32giI/Tux7yGZI9JOtRlEcq7iPC2XxijFnlUPDlds3R+9RRALN9MtQ newZm0sttINIWtfvpdWQqtxg/zm96n6vHbTkD/ymoX0lZ7FLepqJmEYp1jd6GvbA T8PrEi8PNihgb5xGoaDwCho1HlMPMMkupungJ6bwJpM= =935+ -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.
Re: pyramids and pylons
On Nov 6, 1:46 pm, Jeff Tchang jeff.tch...@gmail.com wrote: As a long time user of Pylons the thing that scares me is migration. How much work is it going to take to get my Pylons 9.7/1.0 project to Pyramid. Also since I have projects currently being worked on in Pylons how much of this is going to be dead end work? http://cd34.com/blog/framework/pylons-1-0-to-pyramid-1-0a1/ I had an undeployed Pylons 1.0 project that we had started working on about three weeks ago. We used repoze.who/repoze.what (I do not have Pyramid's auth working with an SQL backend yet) and FormAlchemy along with a number of webhelpers for pagination and constants. It took about 16 hours to convert 35 actions in three controllers to Pyramid. Of that 16 hours, I'd guess that 12 hours was learning Pyramids, reading the documentation, learning how Pyramid did things - I had looked at repoze.bfg in the not too distant past, and getting pointers on IRC to documentation and methodologies behind Pyramid. With that said. Pylons 1.0 isn't going away for a long time. It probably won't see many feature upgrades but will receive bugfixes for stability/security. I don't think I would worry about a project currently using 0.9.7/1.0 being orphaned and unsupported. While Pyramid is tagged as an Alpha release, it is a very mature Alpha. I do believe that we'll be using Pyramid for new development and as we work out some of the pitfalls we run into, I'll post the solutions we find. -- 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.
Re: pyramids and pylons
I'm not an authority on the matter but I'll respond anyways. Note that I will probably over generalize and water down things, and may be plain wrong but it should help give you some idea anyways. pyramid is basically a renamed repoze.bfg, which was a framework made by the zope folks in an attempt to take useful things from zope and make them easier to use. I'd say they've done a wonderful job, since as of about 3 months ago I've converted over all my projects to repoze.bfg and now pyramid. Pyramid is basically the future of pylons afaik. But there 'are' controllers, they're just not named such. The current wording is handlers, which are basically the same as controllers. Hope that helps! William Chambers On Nov 4, 7:44 pm, Kevin J. Smith ke...@ryzoe.com wrote: Hi, 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? Cheers -- 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.
Re: pyramids and pylons
On Thu, Nov 4, 2010 at 4:44 PM, Kevin J. Smith ke...@ryzoe.com wrote:
Hi,
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?
The Pylons 2 codebase has been going in a BFG-ish direction for
several months (search pylons-discuss and pylons-devel for marco and
bfg). Pyramid is just a new name for it. It hasn't been announced
yet so your surprise is understandable.
Basically, the Pylons and BFG developers decided to merge their
codebases into one framework. So Pyramid is a fork of BFG with all the
Pylons 2 stuff merged in (and Routes too). The name Pylons has grown
from being a single framework to a developer community that maintains
three frameworks: Pylons 1, BFG 1.3, and Pyramid. TurboGears is
considering joining the merger but has not yet committed to it. It
depends on whether they decide to rebase TG on Pyramid or stick with
Pylons 1.
Pyramid supports multiple API styles. Configuration can be imperative
(Pylons-style: instantiating objects and calling methods) or
declarative (BFG-stye: an XML-based configuration file). Routing can
be transversal (a la TurboGears) or URL dispatch (Routes-style). The
Pyramid manual is forked from the BFG book, but it's being geared
toward the Pylons style, so imperative and with URL dispatch.
Pyramid has a different MVC vocabulary. The model is the model, but
the view is the callable that processes the request, so the equivalent
of a Pylons action method. A view handler is a class containing view
methods, so the equivalent of a controller. This was just documented
today, so read the chapter on View Handlers. Some of the chapters
in the manual refer to Pyramid's other modes, so they're irrelevant to
a Pylons-style application. I'm making a howto to explain the relevant
parts.
There are some changes in the syntax. Routes configuration changes to
``config.add_hander()`` or ``config.add_route()``. A view method looks
like this:
class MyViewHandler(object):
def __init__(self, request):
self.request = request
@action(renderer=/index.mako)
def my_view(self):
return {var1: value 1}
This, obviously, is TurboGears-ish, but not exactly the same. You can
mount a Pylons 1 application as a URL overlay, so that you can upgrade
it one page at a time, or add new pages but keep the old pages as-is.
Only a small part of Zope is coming in: the component architecture and
interfaces. Application developers don't need to worry about that,
it's all preconfigured in the Paster application template. The
component architecture is a generic plugin system: it allows you -- if
you want -- to switch out and replace parts of the framework as easily
as switching template engines. It allows the components, routing, and
configuration data to all be specified in the same format in the same
configuration file, if desired. But a normal Pylons-like application
would not do this, it would use a familiar INI file, and a module
that's equivalent to environment/middleware/routing.py
--
Mike Orr sluggos...@gmail.com
--
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.
Re: pyramids and pylons
On Thu, Nov 4, 2010 at 11:40 PM, Andrew Kou andrew@gmail.com wrote: Whoa, so Pylons (the framework) is being killed off? The framework named Pylons will remain 1.x, and will be used and maintained for several years. The part of Pylons that is in the ``pylons`` package is actually pretty small (and has been getting more simplified and smaller in the past few versions), so there's not much to maintain. Most of the bugs that get reported are in the dependency packages. The version that was going to be Pylons 2 is now called Pyramid. -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramids and pylons
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 daniel On Nov 5, 7:52 am, Mike Orr sluggos...@gmail.com wrote: On Thu, Nov 4, 2010 at 11:40 PM, Andrew Kou andrew@gmail.com wrote: Whoa, so Pylons (the framework) is being killed off? The framework named Pylons will remain 1.x, and will be used and maintained for several years. The part of Pylons that is in the ``pylons`` package is actually pretty small (and has been getting more simplified and smaller in the past few versions), so there's not much to maintain. Most of the bugs that get reported are in the dependency packages. The version that was going to be Pylons 2 is now called Pyramid. -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramids and pylons
On Nov 5, 5:34 am, daniel daniel...@orange.fr 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 .. More specific criticism would be helpful. 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've spent ten years using Zope. Pyramid is not Zope. It does use several packages in the zope namespace, but end users never use or need to care about those packages. They're a framework implementation detail. - 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-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.
Re: pyramids and pylons
On Nov 5, 5:44 am, chrism chr...@plope.com wrote: 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've spent ten years using Zope. Pyramid is not Zope. It does use several packages in the zope namespace, but end users never use or need to care about those packages. They're a framework implementation detail. And by the way: Pyramid is 5,000 lines of non-test code. Django is about 60,000 (of non-test code). If Django is simpler than Pyramid, then we better check the laws of physics for loopholes. -- 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.
Re: pyramids and pylons
No criticism at all, although it would be nice getting the relevant user's benefits of the change. The complexity I talked about as well the allergy to zope is a personal perception I would wish expressing here (perhaps I'm the only one feeling that, then just don't care about it) I decided to jump from django to pylons beacuse I felt pylons to be open and simple. I enjoyed using it and I wish thanking immensely all the contributors My allergy to the name of zope shall play a role in personal future decisions, whichever portion of it is going to be used here Complexity is measured to my way of thinking from a user perspective, not necessarly from a framework code number of lines developer point of view Regards Daniel On Nov 5, 10:44 am, chrism chr...@plope.com wrote: On Nov 5, 5:34 am, daniel daniel...@orange.fr 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 .. More specific criticism would be helpful. 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've spent ten years using Zope. Pyramid is not Zope. It does use several packages in the zope namespace, but end users never use or need to care about those packages. They're a framework implementation detail. - 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-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.
Re: pyramids and pylons
On Nov 5, 7:15 am, daniel daniel...@orange.fr wrote: No criticism at all, although it would be nice getting the relevant user's benefits of the change. The complexity I talked about as well the allergy to zope is a personal perception I would wish expressing here (perhaps I'm the only one feeling that, then just don't care about it) I'm sorry you feel that way. The Zope brand has certainly taken its share of lumps over the years, and has a reputation for being insular and mysterious. But the word Zope is meaningless without qualification. What *part* of Zope do you hate? Zope is a brand, not a technology. If it's Zope2-the-web-framework, Pyramid is not that. The primary designers and developers of Pyramid, if anyone, should know. We wrote Pyramid's predecessor (repoze.bfg), in part, because *we* knew that Zope 2 had usability issues and limitations. repoze.bfg (and now Pyramid) was written to address these issues. If it's Zope3-the-web-framework, Pyramid is *definitely* not that. Making use of lots of Zope 3 technologies is territory already staked out by the Grok project. Save for the obvious fact that they're both web frameworks, Pyramid is very, very different than Grok. Grok exposes lots of Zope technologies to end users. On the other hand, if you need to understand a Zope-only concept while using Pyramid, then we've failed on some very basic axis. If it's just the word Zope: it's, charitably, only guilt by association. You need to understand that just because a piece of software internally uses some package named ``zope.foo``, it doesn't turn the piece of software that uses it into Zope. There is a lot of *great* software written that has the word Zope in its name. Zope is not some sort of monolithic thing, and a lot of its software is usable externally. It's not really my job to defend Zope. But Zope has been around for over 10 years and has an incredibly large, active community. If you don't believe this, http://taichino.appspot.com/pypi_ranking/authors is an eye-opening reality check. Complexity is measured to my way of thinking from a user perspective, not necessarly from a framework code number of lines developer point of view It's pretty hard to defend Pyramid against charges that won't be disclosed. - 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-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.
Re: pyramids and pylons
On Fri, Nov 5, 2010 at 2:34 AM, daniel daniel...@orange.fr 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 .. The Pyramid book is a reference manual so it contains all the details. More Pylons-specific guides will be coming but they're not written yet. That's why the project is still in alpha. The benefits in short are more flexibility and unifying some API paradigms that have sprouted up in different frameworks since WSGI was invented. Ben can explain it better than I can, just be patient. :) And Pylons 1 is not going away. I'm still running Pylons 0.9.7 applications which are just now being converted to Pylons 1. -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramids and pylons
-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
Re: pyramids and pylons
So as a user what matters to me is that I can still continue to:
1) use SQLAlchemy to fetch stuff
2) call some backend modules with that data
3) maybe store the results in Beaker
4) then send those results to Mako
I suspect this is probably going to be the case, so I'm cool.
Any incompatibilities are par for the course for a major numbered upgrade.
There are some changes in the syntax. Routes configuration changes to
``config.add_hander()`` or ``config.add_route()``. A view method looks
like this:
class MyViewHandler(object):
def __init__(self, request):
self.request = request
@action(renderer=/index.mako)
def my_view(self):
return {var1: value 1}
--
David Gardner
Pipeline Tools Programmer
Jim Henson Creature Shop
dgard...@creatureshop.com
--
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.
Re: pyramids and pylons
My $0.02 USD: As a longtime Pylons classic (1.x) and sometimes Zope 3 user, I'm intrigued by Pyramids. A disclaimer: I was not fond of classical Zope 3 development. Since I worked with a longtime Zope veteran (Jeff Shell), I know why Zope 3 was an architectural improvement over Zope 2. But the application development experience left a lot to be desired for me personally (the ZCML requirement was one but not the only reason). However, the essence of the ZCA was promising and I've followed the grok and repoze initiatives with great interest as they experimented with ways to free Zope 3 from Zope 3. The ZCA exists to free web framework developers from endless subclassing. Zope 2 had endless subclassing and it began to wear on people. Zope 3 was a radical break to free the Zope community from the same problems that Mr. Bangert is facing with Pylons 1.x. The ZCA unfortunately came about at a time when XML and Javaish enterprisy terminology was all the rage and it reflects its passage through that dark time. However, the vast, vast, vast, vast, vast, vast, vast majority of Pylons web _application_ developers would never have to face the agony of the raw ZCA, ZCML, or interfaces. That's something for framework nerds and hardcore Zope veterans. Core ZCA components like zope.component and zope.interface as well as other Zope components are over five years old and rock solid. It's merely their usability that has largely fallen short. Pyramids has the potential to bring things the Zope community has had for years down from the mountaintop to a larger community. In truth, the Zope legacy is little more than an asterisk to future Pylons development. If Pylons/Pyramids/whatever is successfully packaged and sold, Zope 3 may receive vindication in the end. Especially if people don't realize they're using Zope 3. -- 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.
Re: pyramids and pylons
Yeah, the main issue is that I think the new structure at a high level can be a little confusing, since the Pylons name is changing from a framework to a project. The distinction between Pylons 1.0 and Pylons project makes it difficult to relay the Pylons name and the fact that Pyramid is a standalone framework kind of adds to the confusion. I can see a potentially common questionSo...is Pyramid the new Pylons 2.0?. I think it is important that it is stressed pretty heavily in docs/site etc that Pylons 1 isn't being killed off. I think a lot of people are misunderstanding and getting the impression that this is the case for one reason or another. Another issue I can see is that people don't understand what the difference of the changes are. Maybe a simple high level diagram would help? (I don't know if that is even possible, just a suggestion) Best, - Pyeek On Fri, Nov 5, 2010 at 9:31 AM, lcrees lcr...@gmail.com wrote: My $0.02 USD: As a longtime Pylons classic (1.x) and sometimes Zope 3 user, I'm intrigued by Pyramids. A disclaimer: I was not fond of classical Zope 3 development. Since I worked with a longtime Zope veteran (Jeff Shell), I know why Zope 3 was an architectural improvement over Zope 2. But the application development experience left a lot to be desired for me personally (the ZCML requirement was one but not the only reason). However, the essence of the ZCA was promising and I've followed the grok and repoze initiatives with great interest as they experimented with ways to free Zope 3 from Zope 3. The ZCA exists to free web framework developers from endless subclassing. Zope 2 had endless subclassing and it began to wear on people. Zope 3 was a radical break to free the Zope community from the same problems that Mr. Bangert is facing with Pylons 1.x. The ZCA unfortunately came about at a time when XML and Javaish enterprisy terminology was all the rage and it reflects its passage through that dark time. However, the vast, vast, vast, vast, vast, vast, vast majority of Pylons web _application_ developers would never have to face the agony of the raw ZCA, ZCML, or interfaces. That's something for framework nerds and hardcore Zope veterans. Core ZCA components like zope.component and zope.interface as well as other Zope components are over five years old and rock solid. It's merely their usability that has largely fallen short. Pyramids has the potential to bring things the Zope community has had for years down from the mountaintop to a larger community. In truth, the Zope legacy is little more than an asterisk to future Pylons development. If Pylons/Pyramids/whatever is successfully packaged and sold, Zope 3 may receive vindication in the end. Especially if people don't realize they're using Zope 3. -- 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.compylons-discuss%2bunsubscr...@googlegroups.com . 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 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.
Re: pyramids and pylons
On Fri, Nov 5, 2010 at 9:24 AM, David Gardner dgard...@creatureshop.com wrote: So as a user what matters to me is that I can still continue to: 1) use SQLAlchemy to fetch stuff 2) call some backend modules with that data 3) maybe store the results in Beaker 4) then send those results to Mako Yes for 1, 3, and 4. I'm not sure what you mean by #2. Pyramid has a Paster template called pyramid_sqla that preconfigures a SQLAlchemy+Mako application to the same level as Pylons 1. I think it also includes Beaker but I'm not 100% sure about that. In any case, the pyramid-beaker plugin is already written. And Pyramid includes an equivalent to Routes, which is in the process of gaining all of Route's features. Pyramid includes a sopisticated auth system that's more integrated than Repoze.who/what. It looks like Pyramid does not include a form builder/validator, but you should be able to use FormEncode/WebHelpers or ToscaWidgets or the SQLAlchemy-form packages as usual. (I'll be testing a FormEncode/WebHelpers app soon.) You may have to provide your own code for @validate or an equivalent, at least at this stage. You can define your own lib functions and call them from a view or model. I think that's what you mean by #2? -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramids and pylons
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 gjhigg...@googlemail.com 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.
Re: pyramids and pylons
On Fri, Nov 5, 2010 at 11:58 AM, Eric Rasmussen ericrasmus...@gmail.com wrote: 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. Eric, feel free to play with it. I guess specific questions about using it should go to pylons-devel at this stage, so that Pylons 1 users won't get confused? My proto howto is here but it was written before the Pyramid shift, so some parts are out of date. The usage should be almost the same, just the repository location and package name is different. I'm thinking of a simple Blog+Comments+Auth tutorial using SQLAlchemy if you'd like to collaborate on that. HTML version: http://bytebucket.org/sluggo/pylons2-userguide/wiki/html/index.html Sphinx source: https://bitbucket.org/sluggo/pylons2-userguide -- Mike Orr sluggos...@gmail.com -- 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.
Re: pyramids and pylons
On Nov 5, 2010, at 11:36 AM, Kevin J. Smith wrote:
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.
Yes, some of the beta code I had tried out for Pylons 2.0 would've required a
similar amount of porting as this transition will.
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.
Luckily, pyramid comes with authentication/authorization (built-in, and
optional of course). repoze.what wasn't actually created by the repoze folks,
it was a TG2 project for authorization, which many folks have unfortunately had
a lot of problems with.
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.
I think you'll be able to swap in and replace most anything you'd want to in
pyramid as well, this time using better documented hook and plug-in points,
rather than attempting to glue together more things.
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.
I'll be sending out an announcement later today, but there's no reason people
that want to, can't start kicking the tires now so to speak. Due to the
extremely well documented heritage of bfg, there is ample docs. They are quite
verbose, for good or bad, so people are working on more new-user friendly
guides for the 10k ft view.
Speaking of simplicity, in pyramid, if you have one of those uber-simple little
apps that doesn't need a full Pylons-like project setup, you can actually
create the entire thing in a single module if that's your fancy:
from pyramid.configuration import Configurator
from pyramid.response import Response
from paste.httpserver import serve
class MySite(object):
def __init__(self, request):
self.request = request
def hello(self):
return Response('Hello world!')
if __name__ == '__main__':
config = Configurator()
config.begin()
config.add_handler('home', '/site/:action', handler=MySite)
config.end()
app = config.make_wsgi_app()
serve(app, host='0.0.0.0')
That's it! While some of the terminology is changing, the overall style
(class-type 'controllers') for those coming from Pylons is not. Simple sites
can be simple, and larger ones that need extensibility can actually be
extensible.
Which brings up the point, where can we get our hands on Pylons 2.0 work?
There's a pyramid 1.0a1 release on cheeseshop now, the docs are all over at
http://docs.pylonshq.com/. This is the home for the combined project right now,
and will be further integrated into the main pylonshq site.
Cheers,
Ben
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to 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.
Re: pyramids and pylons
On Fri, Nov 5, 2010 at 8:05 AM, Graham Higgins gjhigg...@googlemail.com wrote: Kevin J Smith wrote: 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?. Chris McDonough wrote: The word Zope is meaningless without qualification. What *part* of Zope do you hate? It's pretty hard to defend Pyramid against charges that won't be disclosed. Less confrontation, Chris, please. Pylons users are legitimately concerned about any sudden changes in the API, abandonment of previously-supported versions, and over-Zopeification. Also, Pyramid is being introduced to them in a haphazard way, rather than an announcement and discussion before the fact as TurboGears had [1] and presumably BFG had. So people are rightly concerned about where Pylons is headed, and asking for more details. [1]: http://groups.google.com/group/turbogears/browse_thread/thread/47779d8587721037?pli=1 The merger/rebanding is very recent -- like a week ago. Graham and I first heard about it four days ago. That's why not all of the pieces are in place yet. The reason for concerns like Kevin's is historical. I (and several WSGI developers) left Zope in 2000 because it was a huge monolith, and the documentation was geared toward content creators rather than Python developers. Zope has since fixed many of these shortcomings: improving the developer documentation, splitting the code into multiple packages, and spawning Repoze and BFG and Grok. But ZCML, component architecture, and interfaces still strike fear into many hearts. And Zope's greatest accomplishment -- Plone -- is still tied to Zope 2, and is still more monolithic than many here would like. The fears about Pylons are legitimate and need to be addressed. We just need to have a dialog about what exactly is coming from Zope, why it won't destroy Pylons, and what its benefits are. The other concern is abandonment of previous versions. Many people were not happy with the move from TurboGears 1 to TurboGears 2. They complained that the TG book was published right when its developers were starting to move away from that paradigm, and that the window between TG1 and TG2 was unusually short by framework standards. This forced people to invest in TG1 and then immediately rewrite their apps for TG2, or stick with TG1 which was now less-supported than they had been expecting. So people are rightly concerned that Pylons mustn't do that. Still, the state of the art evolves quickly, so some change is inevitable. My message to Pylons users is: the developers share your concerns. We asked the same questions of Chris when we were first considering BFG and a component architecture. We hate XML just as much as you do. We asked, What would a component architecture gain us? Are there any alternative non-Zope implementations? Are these pieces separable from the rest of Zope? How much Zope is enough and how much is too much? It turns out that that the Zope developers were smart to see the benefits of components/interfaces early on, and they were willing to split that out for the rest of us, just as they had earlier split out ZODB. There is no alternative Python package for this that has been as well tested over several years, especially in a web-framework environment. When Chris first explained the XML-based configurator, our first comment was, That will be unacceptable to Pylons users. So he made a flexible configuration backend, envisioning multiple configuration styles (XML, Python, INI, etc). Only the XML and Python styles have been pursued. (The Paste INI file is not directly related to this. The upshot for Pylons users is a Python module equivalent to environment/middleware/routing.py .) 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, And anyone is free to help with maintenance or take on feature enhancements -- with Ben's approval. But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies. @validate needs a replacement; that's the only thing I can think of. 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 :-) What is the flaw? The footnote seems to have been omitted. Architecturally, BFG is conceptually very similar to Pylons. Chris looked very carefully at Pylons when he
Re: pyramids and pylons
Hi all, Thanks to especially Graham and Mike to point out what the benefit for the end-user-developer (a crude term, I know ;) ) will be with the Pylons2/Pyramid move. When I started to read these posts, I was a bit concerned, too. I (we, my company) have been long time Pylons users, and admittedly, we have seen more changes in Pylons than we liked. I could understand the reasoning behind all those changes, still, for the developer they pose a hazard in long-term-evolution of a written app. Some of the things I mean: - The deprecation of rails-style webhelpers. We depend on those quite a bit in our first application we wrote (and which is still live) - Change in how to address a template (from package.template to package/template.mak) - The move from implicit routes to explicit routes And if I thought a bit more, I would probably come up with a couple of more examples, which have been problematic for us. The problem in there is, that there normally is no smooth upgrade path, and no backwards compatibility, so we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, as no one would pay us a money for the complete rework the older apps need, as for the customer, it would mean very little benefit. Don't get me wrong, I love pylons, and the first question we ask ourselves when a new project comes in is, Can we solve this in pylons, or do we have to implement it with something different?, but the lack of continuity has been a bit disheartening at times. Still, I would really be interested in why the subclassing of WSGIController lead Pylons in an architectional dead end, just from a curious point of view :) I will take a look at the new packages as soon as I get around to it, but I'm really curious by now. But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies. @validate needs a replacement; that's the only thing I can think of. Maybe not the Pylons package itself (and I personally had no trouble using @validate up to now), but one thing the whole Pylons eco system would hugely benefit from (imo) is a database migration tool. I have looked into those which have been announces (miraku and a couple of others), and all fall short. I have written something like that for ourselves, for SQLAlchemy based projects, which takes the model, evaluates the differences between the current model revision, and the latest from the versioning system, and generates the appropriate SQL scripts for getting the database from the one version to the next, without loss of data. I always hoped of releasing it to the public at some point, but I never really had the time to get around to it. It is stable we are using it for a couple of our projects, but it is lacking the real hard stuff (like documentation, and things not that tied to our own infrastructure ;) ) Regards, Jens -- 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.
Re: pyramids and pylons
On Nov 5, 3:55 pm, Mike Orr sluggos...@gmail.com wrote: Less confrontation, Chris, please. Pylons users are legitimately concerned about any sudden changes in the API, abandonment of previously-supported versions, and over-Zopeification. Also, Pyramid is being introduced to them in a haphazard way, rather than an announcement and discussion before the fact as TurboGears had [1] and presumably BFG had. So people are rightly concerned about where Pylons is headed, and asking for more details. Right you are, Mike. Thanks for being the voice of reason. - 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-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.
Re: pyramids and pylons
On Nov 5, 2010, at 1:50 PM, Jens Hoffrichter wrote: Thanks to especially Graham and Mike to point out what the benefit for the end-user-developer (a crude term, I know ;) ) will be with the Pylons2/Pyramid move. When I started to read these posts, I was a bit concerned, too. I (we, my company) have been long time Pylons users, and admittedly, we have seen more changes in Pylons than we liked. I could understand the reasoning behind all those changes, still, for the developer they pose a hazard in long-term-evolution of a written app. Some of the things I mean: - The deprecation of rails-style webhelpers. We depend on those quite a bit in our first application we wrote (and which is still live) No worries, these are not dead! The WebHelpers package isn't going anywhere, and its still easy to use throughout your templates. - Change in how to address a template (from package.template to package/template.mak) Ah, sorry if that's confusing. The dotted notation for a full 'resource specification' is optional: http://docs.pylonshq.com/pyramid/dev/narr/views.html#mak-or-mako-mako-template-renderer You can and do of course, configure Mako to have a template directory, and relative names like 'foo.mak' are assumed to exist in said template dir. The ability to use a full resource specification addresses a long-time noted issue with extending or re-using packages of your templates. While Mako lets you plugin multiple template paths, the overlap can get tricky to manage, being able to refer to a template with its package name is specifically to allow you to use templates that might be in another package for extending purposes. Consider the case where you have a set of templates you use in all your projects, wouldn't it be nice to have a package of those you just call into? And if you needed to tweak just one of those, you could override it with a template of your choice via the override API: http://docs.pylonshq.com/pyramid/dev/narr/resources.html#the-override-resource-api This is the start of where many frameworks are telling you to fork code ;) - The move from implicit routes to explicit routes Yes, all routes do have to be explicit. I was moving that way in Pylons 1.x with Routes already actually, as the implicit naming and resolving done in Routes generally leads to more problems for users, than helping. And if I thought a bit more, I would probably come up with a couple of more examples, which have been problematic for us. The problem in there is, that there normally is no smooth upgrade path, and no backwards compatibility, so we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, as no one would pay us a money for the complete rework the older apps need, as for the customer, it would mean very little benefit. I've tried to provide as smooth an upgrade path as possible between various versions of Pylons. From the upgrade path's I've seen in other web frameworks, its one of the smoother ones... but the fact that so much configuration was in Python files rather than the framework has been very problematic as extensive changes are needed for upgrades as half the 'framework' is more or less assembled in the project itself. pyramid does not have this issue, as rather than having all its configuration innards in your project, you configure pyramid via hook points. Don't get me wrong, I love pylons, and the first question we ask ourselves when a new project comes in is, Can we solve this in pylons, or do we have to implement it with something different?, but the lack of continuity has been a bit disheartening at times. Still, I would really be interested in why the subclassing of WSGIController lead Pylons in an architectional dead end, just from a curious point of view :) http://be.groovie.org/post/1347858988/why-extending-through-subclassing-a-frameworks is my main summary of the problems. I also have a bit more on this on the faq question here: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base I will take a look at the new packages as soon as I get around to it, but I'm really curious by now. But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies. @validate needs a replacement; that's the only thing I can think of. Maybe not the Pylons package itself (and I personally had no trouble using @validate up to now), but one thing the whole Pylons eco system would hugely benefit from (imo) is a database migration tool. I have looked into those which have been announces (miraku and a couple of others), and all fall short. I'd love to spend more time on getting an 'official' one hammered out. Part of the reason for combining efforts, and going with pyramid for the base is that we need a strong, stable, extensible system to start building more helpful higher level tools. With a larger team of
Re: pyramids and pylons
You might want to take a look at the (still-being-revised) http://docs.pylonshq.com/#faq for the general FAQ. There should be an announcement up very soon. It probably won't have much more info than that has. For the fear of no-controllers, see: - http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-gets-its-terminology-wrong-mvc - http://docs.pylonshq.com/pyramid/dev/narr/handlers.html Handlers == Pylons 1.X controllers. For the fear of Zope, please see: - http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-encourages-use-of-zcml - http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-uses-a-zope-component-architecture-zca-registry If you spend some time reading the docs you'll see that it using the framework as an end user really has nothing at all to do with Zope. On Nov 4, 7:44 pm, Kevin J. Smith ke...@ryzoe.com wrote: Hi, 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? Cheers -- 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.
