Re: Some thoughts about Pyramid
On 05/03/2011, at 7:00 AM, Mike Orr sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis palexis2...@gmail.com wrote: I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. I feel more or less same, 'coz I was finding much difficulty in understanding the framwork from the document. Escpecially, the registration, configuration, the Z* things etc... The framework is so powerful, but lack of clean medium to get into it causing people to take U turn. It would be much better if we can re- arrange/modify the documents in a way to take out Z* things, traversal and all complex topics to 'Advance' section seperately. This is where Pyramid's multiple goals come into play. The BFG-ish users say that Traversal was immediately understandable to them and they could apply it right away, while they find URL Dispatch cumbersome. ZCML configuration was moved to the back of the manual for exactly the reason you describe, because it was a stumbling block for the large number of Pylons users who were about to come, and the BFG users knew where to find it in the back of the manual. I'd support moving Traversal to the back except I think there'd be more resistance to doing that than there was for ZCML. Traversal is central to an application if you're using it, whereas ZCML is just zis configuration format, y'know. [voice of Zaphod Beeblebrox's psychiatrist] I'm a big traversal fan (coming from zone/plone) but they do make a compelling case that traversal could be confusing to choose between when you are new. Seems like traversal is a bit like OO. Its solving a problem you are only going to have when you start to write more complicated apps. People teach python as a first language now instead of java so they don't have to explain OO before people understand the need for it. So I think it's compelling to describe traversal in the manual as an advanced routing feature and make it more clear exactly what scenarios traversal is good for and why it's a great solution for those. I don't think that means moving traversal to the back because its too important. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en . -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On 2011-3-17 15:59, Dylan Jay wrote: So I think it's compelling to describe traversal in the manual as an advanced routing feature and make it more clear exactly what scenarios traversal is good for and why it's a great solution for those. I don't think that means moving traversal to the back because its too important. I don't agree with that. Traversal is not 'advance' or 'more difficult'. It just approaches the URL-data+code mapping problem in a way which works great when dealing with a hierarchical data structure. That is not handled very well (I'm even tempted to say 'badly') by routing approaches. As a test I explained it that way in a training session this week, and everybody seemed to get the distinction directly. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On 04/03/2011 20:03, Mike Orr wrote: I'll be at the Pyramid sprint but I don't know what I'll be doing. I would like to learn Git and Pyramid-at-Github if somebody would like to do a mini crash course. Me too please! I'm currently petrified of all things git and could use some hand holding. I'm eyeing up those two small venusian issues as training bait for this... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Thu, 2011-03-03 at 23:42 -0800, Peter Alexis wrote: I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. I feel more or less same, 'coz I was finding much difficulty in understanding the framwork from the document. Escpecially, the registration, configuration, the Z* things etc... The framework is so powerful, but lack of clean medium to get into it causing people to take U turn. It would be much better if we can re- arrange/modify the documents in a way to take out Z* things, Can you explain which Z things we'd take out? What Z things are you tripping over? traversal and all complex topics to 'Advance' section seperately. So that, people interested in squeezing full power/flexibility can go through those section while beginners or who come from other framework or technologies can feel better easly and start working on. I'm pretty sure, people would consider/refer advance section once they feel comfortable. So we should reorganize by moving chapters of the documentation around? But Its almost certain that, without un-cluttered, well organized document, its difficult to attract and get more contribution towards Pyramid. No doubt we can do better. - C my 2 cents. On Mar 4, 1:34 pm, Jonathan Vanasco jonat...@findmeon.com wrote: I think the criticisms in the post -- and their defense here -- are really important. I've had the same struggles. While many are not technically valid , they appear to be so because of the documentation and positioning of pyramid. Pyramid is really powerful framework, but its also quite low-level. Most frameworks are high-level. While this can be very powerful, it can also be frustrating. As an example, look at the concept of Auth -- the pyramid auth system is ( unless there are new magical docs out there ) very much positioned at doing some fine-grained authentication ( users, groups, actions) based on each 'view'. Most other frameworks use advanced plugins for this sort of functionality... and have much simpler plugins to handle authentication for each handler / controller / etc as a package. ie: for the majority of web applications, the state of being logged in is the only requirement for access to every method of a class/package, and having to (re)declare auth policies per method becomes daunting. I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
One also just needs to define what the ultimate goal is: Is it to compete with Django/Rails? In that case I agree that alot of work needs to be done on simplifying and removing options. The power of Django/ Rails are that they provide one way of doing things that works in the most cases. The problem is that it is very difficult if you want to go outside the constraints imposed by them. Django is very good at what it does, and its very simple to quickly create a CRM/blog style app. When I want to build that type of app, I'll definitely use Django. But it's when I have to build something different that Pyramid really shines. For example, at the beginning of this year I started building a multi- site CRM system. One of the requirements for this was that one installation should be able to administrate several different domains. I started by using Django, but just to be able to serve different domains from one installation involved several hacky steps. With Pyramid, along with traversal and interfaces, I could replace all of this with one small function that returned the correct root object based on the current domain. In my mind it comes down to using the correct tool for the job - don't use Pyramid if you are building a simple blog - Django is a much more mature system for that. Use Pyramid if you need to do something outside of the constraints imposed by a more rigid system like Django. In my mind we still need something that works on Django level, with more constraints imposed, but I am expecting that the new version of TurboGears based on Pyramid would address that. On Mar 4, 9:42 am, Peter Alexis palexis2...@gmail.com wrote: I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. I feel more or less same, 'coz I was finding much difficulty in understanding the framwork from the document. Escpecially, the registration, configuration, the Z* things etc... The framework is so powerful, but lack of clean medium to get into it causing people to take U turn. It would be much better if we can re- arrange/modify the documents in a way to take out Z* things, traversal and all complex topics to 'Advance' section seperately. So that, people interested in squeezing full power/flexibility can go through those section while beginners or who come from other framework or technologies can feel better easly and start working on. I'm pretty sure, people would consider/refer advance section once they feel comfortable. But Its almost certain that, without un-cluttered, well organized document, its difficult to attract and get more contribution towards Pyramid. my 2 cents. On Mar 4, 1:34 pm, Jonathan Vanasco jonat...@findmeon.com wrote: I think the criticisms in the post -- and their defense here -- are really important. I've had the same struggles. While many are not technically valid , they appear to be so because of the documentation and positioning of pyramid. Pyramid is really powerful framework, but its also quite low-level. Most frameworks are high-level. While this can be very powerful, it can also be frustrating. As an example, look at the concept of Auth -- the pyramid auth system is ( unless there are new magical docs out there ) very much positioned at doing some fine-grained authentication ( users, groups, actions) based on each 'view'. Most other frameworks use advanced plugins for this sort of functionality... and have much simpler plugins to handle authentication for each handler / controller / etc as a package. ie: for the majority of web applications, the state of being logged in is the only requirement for access to every method of a class/package, and having to (re)declare auth policies per method becomes daunting. I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Am 04.03.2011 09:11 schrieb mjmein: In my mind we still need something that works on Django level, with more constraints imposed, but I am expecting that the new version of TurboGears based on Pyramid would address that. That's also my understanding. Our experience with the TG project is also that users really dislike if you force them to make choices. For instance, when TG2 was still young, it was difficult to choose between the more mature TG1 or the upcoming TG2. And then you also had the choice between SQLObject and SQLAlchemy, between Kid and Genshi, etc. The choice between traversal and dispatch presents a similar difficulty to new Pyramid users. Newbies hate such choices because when they start using a framework, they don't have enough experience to make an educated decision and they fear that they will waste a lot of time if they make the wrong choice in the beginning. That's why I think it's a good idea to build an opinionated framework on top of Pyramid where those choices have been made for you that will work best in the majority of cases. Regarding documentation, Donald Knuth's technique of simplifying things in the first chapters and mentioning the exceptions and alternatives only later may be helfpful for newbies: (From the TeXbook: Another noteworthy characteristic of this manual is that it doesn't always tell the truth ... The author feels that this technique of deliberate lying will actually make it easier for you to learn the ideas. Once you understand the simple but false rule, it will not be hard to supplement that rule with its exceptions.) -- Christoph -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Re: Excessive dependencies. Right now when you 'pip install pyramid' on a fresh environment, you get 18 packages installed: Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb, pyramid, repoze.lru, translationstring, venusian, zope.component, zope.configuration, zope.deprecation, zope.event, zope.i18nmessageid, zope.interface, zope.schema What about this alternative: Instead of installing all the possible dependencies in advance, we only install the bare minimum* needed to generate a project template and populate the project's setup.py (or requirements.txt) with all the necessary additional dependencies depending on which template was used or what options were chosen. Perhaps we could even auto-pip install -r requirements.txt as soon as the project template is created. This would cut down the base pyramid dependencies to just pyramid and Paste*, and the consequent project dependencies would be a few shorter than the total. Sounds like there is probably a magnitude of reasons why this is a bad idea, but worth bringing up. [*] Or perhaps instead of the absolute bare minimum, it could be a reasonable minimum. - shazow -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Psychologists have done a significant amount of research documenting the tyranny of choice and famously served samples of exotic jams when choice is demotivating ( http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf). At least for jam, 6 choices is OK, while 30 choices are demotivating. Even the individuals who were able to choose one of the 30 jams were more likely to be dissatisfied and unsure whether they had made the right choice. So if you have less than 10 years experience and think you should re-write a trivial dependency such as Linux, Python, OpenSSL, M2Crypto, zope.component, WSGI, Pyramid, (insert favorite 5 templating languages and 6 forms libraries here), it might not be because those are unsuitable but because you feel more competent at coding than at making a choice. Is it possible to teach newcomers how to deal with the tyrannical, overwhelming level of choice presented by every layer of web application development in Python? -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
The tyranny of choice study gets thrown around a lot, but when there are familiar options it's less of a problem. And there's the opposite problem, not enough choices also presents problems. I can't find the study, but notice all the different kinds of spaghetti sauce in the isle at the supermarket. Some people vastly prefer chunks of vegetables, others are very strongly opposed to that kind of sauce. Providing options expanded the market significantly as folks who had traditionally not liked the product at all found a variety that fit their tastes. IMHO, The trick is not removing all choice, or having the maximum number of options possible -- it's allowing just the right number of choices in just the right places. --Mark Ramm On Fri, Mar 4, 2011 at 10:19 AM, Daniel Holth dho...@gmail.com wrote: Psychologists have done a significant amount of research documenting the tyranny of choice and famously served samples of exotic jams when choice is demotivating (http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf). At least for jam, 6 choices is OK, while 30 choices are demotivating. Even the individuals who were able to choose one of the 30 jams were more likely to be dissatisfied and unsure whether they had made the right choice. So if you have less than 10 years experience and think you should re-write a trivial dependency such as Linux, Python, OpenSSL, M2Crypto, zope.component, WSGI, Pyramid, (insert favorite 5 templating languages and 6 forms libraries here), it might not be because those are unsuitable but because you feel more competent at coding than at making a choice. Is it possible to teach newcomers how to deal with the tyrannical, overwhelming level of choice presented by every layer of web application development in Python? -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Guys, I'll be at PyCon and would like to sprint on this. Maybe a tutorial with code. Anyone? Carlos de la Guardia On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote: So the thing we can carry away from this discussion is that we should improve Pyramid's new user experience, with tutorials and perhaps some defaults for basic functionality. We hold these truths to be self evident... - C On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs to switch to a better library, and users have to adjust their applications. But overall we're glad that users and framework developers can switch libraries as they see fit, and that we can use the latest gee-whiz library as soon
Re: Some thoughts about Pyramid
On Thu, 2011-03-03 at 19:09 -0600, Carlos de la Guardia wrote: Guys, I'll be at PyCon and would like to sprint on this. Maybe a tutorial with code. Anyone? I'd be up for that, although I'm also slated to help port WebOb to Py3k. Carlos de la Guardia On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote: So the thing we can carry away from this discussion is that we should improve Pyramid's new user experience, with tutorials and perhaps some defaults for basic functionality. We hold these truths to be self evident... - C On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs
Re: Some thoughts about Pyramid
For the record, Bottle takes this tact. It's full feature set actually depends on many, many packages (many more than Pyramid does). But it ships as a single file with no dependencies. I'm not a huge fan of this. Maybe it's a successful marketing gimmick but it doesn't actually reduce any complexity. - C On Fri, 2011-03-04 at 08:52 -0800, Thomas G. Willis wrote: that's not a bad idea. I'm using pyramid on app engine, and don't need chameleon, but if I don't push chameleon up to the cloud the app fails to load last time I tried it. of course defining the bare minimum would probably be a challenge. :) -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote: Re: Excessive dependencies. Right now when you 'pip install pyramid' on a fresh environment, you get 18 packages installed: Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb, pyramid, repoze.lru, translationstring, venusian, zope.component, zope.configuration, zope.deprecation, zope.event, zope.i18nmessageid, zope.interface, zope.schema Pyramid depends on 12 distributions directly, the other 7 are transitive dependencies (you missed setuptools above). The dependency graph looks like this: Pyramid | |--- setuptools | |--- Chameleon | |--- Mako | | | -- MarkupSafe | |--- PasteScript || || Paste | |--- PasteDeploy || || Paste | |--- WebOb | |--- repoze.lru | |--- translationstring | |--- venusian | | zope.component | | | | zope.interface | | | -- zope.i18nmessageid | | zope.configuration | | | | zope.interface | | | | zope.schema | | | | zope.i18nmessageid | | | | zope.configuration | | | |--- zope.schema | | | zope.deprecation | | zope.interface Of these, the only ones to very easily *not* install would be Mako, Chameleon, PasteScript, Paste, and PasteDeploy. The others are core dependencies that really can't very easily be externalized. Doing that would take us down to 13 dependencies. We could indeed make pyramid_chameleon and pyramid_mako and pyramid_paste packages to restore the functionality for users of those dependencies. Would that actually service any particular goal? Would having fewer rails in the core actually make anybody happier? - C What about this alternative: Instead of installing all the possible dependencies in advance, we only install the bare minimum* needed to generate a project template and populate the project's setup.py (or requirements.txt) with all the necessary additional dependencies depending on which template was used or what options were chosen. Perhaps we could even auto-pip install -r requirements.txt as soon as the project template is created. This would cut down the base pyramid dependencies to just pyramid and Paste*, and the consequent project dependencies would be a few shorter than the total. Sounds like there is probably a magnitude of reasons why this is a bad idea, but worth bringing up. [*] Or perhaps instead of the absolute bare minimum, it could be a reasonable minimum. - shazow -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Mar 4, 2011, at 12:39 PM, Chris McDonough wrote: On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote: Re: Excessive dependencies. Of these, the only ones to very easily *not* install would be Mako, Chameleon, PasteScript, Paste, and PasteDeploy. The others are core dependencies that really can't very easily be externalized. Doing that would take us down to 13 dependencies. We could indeed make pyramid_chameleon and pyramid_mako and pyramid_paste packages to restore the functionality for users of those dependencies. Would that actually service any particular goal? no Would having fewer rails in the core actually make anybody happier? no Sincerely, anybody - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Sorry to jump in here at the end, but just wanted to put a word in. The extra dependencies are due to the fact that pyramid integrates a lot of other very good packages. This IS a GOOD thing, not bad. It makes pyramid better and those other packages better because there are more stakeholders in those packages. Think about all the neat features Django has and how no other web framework is able to reuse it. It's a shame it's like this, not a sign of a well designed framework(don't get me wrong, I think Django is VERY good). Now I know there isn't a lot of reusable bits that Pyramid uses, really only Chameleon, Webob, Mako and Paste, but it's not a full-stack framework like Django is. I assume TurboGears, once integrated with Pyramid, will integrate a lot of the other web-framwork related packages(ie forms, web helpers, ORM, etc). IMO, entertaining this notion is a waste of time. I enjoy all the decoupled packages the repoze/pyramid project creates--it's a sign of some really great development. Pyramid is taking a different route than other frameworks do, maybe better(it's all opinions..). I do feel for beginners who don't know what to do about authentication and authorization--I know I at first got hung up on that. I think pyramid could ship with a sane authtkt, acl, basic auth, htpasswd enabled setup so beginners starting don't have to think about it. Even though, providing your own authentication integration is trivial really and almost always depends on your database selection and authorization requirements Or maybe just include something basic in all the templates... -Nathan On Fri, Mar 4, 2011 at 11:55 AM, Reed L O'Brien reedobr...@gmail.comwrote: On Mar 4, 2011, at 12:39 PM, Chris McDonough wrote: On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote: Re: Excessive dependencies. Of these, the only ones to very easily *not* install would be Mako, Chameleon, PasteScript, Paste, and PasteDeploy. The others are core dependencies that really can't very easily be externalized. Doing that would take us down to 13 dependencies. We could indeed make pyramid_chameleon and pyramid_mako and pyramid_paste packages to restore the functionality for users of those dependencies. Would that actually service any particular goal? no Would having fewer rails in the core actually make anybody happier? no Sincerely, anybody - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 12:11 AM, Chris McDonough chr...@plope.com wrote: So we should reorganize by moving chapters of the documentation around? Maybe if we just rename the Pyramid manual to the Pyramid Reference Manual it will set readers' expectations appropriately. I'm not sure if there's anything that needs to change in the manual. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 9:39 AM, Chris McDonough chr...@plope.com wrote: Of these, the only ones to very easily *not* install would be Mako, Chameleon, PasteScript, Paste, and PasteDeploy. The others are core dependencies that really can't very easily be externalized. Doing that would take us down to 13 dependencies. We could indeed make pyramid_chameleon and pyramid_mako and pyramid_paste packages to restore the functionality for users of those dependencies. Would that actually service any particular goal? Would having fewer rails in the core actually make anybody happier? I was -1 on splitting them but as I thought about it more I'm +0. There's a benefit in distinguishing more between what Pyramid itself needs and what the application templates need. If somebody is never going to use Chameleon or Mako, or they detest PasteDeploy, why install them? Especially if it causes problems in space-constrained deployments. The user can't nullify a dependency without changing other packages' setup.py files, and excluding packages manually that then get re-added whenever somebody runs python setup.py install because they think it will just bring the app up to date seems wrong. If we do split them off, we should probably add a paragraph to the templates' documentation saying this template uses X which provides X, or all templates distributed with Pyramid depend on X which provides X. That will keep people fully informed about what decisions the templates are making for them, and what leeway they have to choose alternatives. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
My wishlist for the manual: 1. searching for request.response_headers should pull up request.response_headerlist 2. glossary for 'Configurator' etc. should link to function signatures -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
I'm up too On Mar 3, 8:09 pm, Carlos de la Guardia carlos.delaguar...@gmail.com wrote: Guys, I'll be at PyCon and would like to sprint on this. Maybe a tutorial with code. Anyone? Carlos de la Guardia On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote: So the thing we can carry away from this discussion is that we should improve Pyramid's new user experience, with tutorials and perhaps some defaults for basic functionality. We hold these truths to be self evident... - C On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs to switch to a better library, and users have to adjust their applications.
Re: Some thoughts about Pyramid
Could you put this in the Pyramid issue tracker? On Fri, 2011-03-04 at 14:28 -0500, Daniel Holth wrote: My wishlist for the manual: 1. searching for request.response_headers should pull up request.response_headerlist 2. glossary for 'Configurator' etc. should link to function signatures -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis palexis2...@gmail.com wrote: I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. I feel more or less same, 'coz I was finding much difficulty in understanding the framwork from the document. Escpecially, the registration, configuration, the Z* things etc... The framework is so powerful, but lack of clean medium to get into it causing people to take U turn. It would be much better if we can re- arrange/modify the documents in a way to take out Z* things, traversal and all complex topics to 'Advance' section seperately. This is where Pyramid's multiple goals come into play. The BFG-ish users say that Traversal was immediately understandable to them and they could apply it right away, while they find URL Dispatch cumbersome. ZCML configuration was moved to the back of the manual for exactly the reason you describe, because it was a stumbling block for the large number of Pylons users who were about to come, and the BFG users knew where to find it in the back of the manual. I'd support moving Traversal to the back except I think there'd be more resistance to doing that than there was for ZCML. Traversal is central to an application if you're using it, whereas ZCML is just zis configuration format, y'know. [voice of Zaphod Beeblebrox's psychiatrist] -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, 2011-03-04 at 12:00 -0800, Mike Orr wrote: On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis palexis2...@gmail.com wrote: I mentioned unless there are new magical docs, because I think 99% of the problems with pyramid right now are the docs. They're hard to sift through (rather dense) and easy to miss things in. Meanwhile, docs for projects like Django and Rails are really light and breezy... and link to the more-in-depth specialized docs and api docs. I feel more or less same, 'coz I was finding much difficulty in understanding the framwork from the document. Escpecially, the registration, configuration, the Z* things etc... The framework is so powerful, but lack of clean medium to get into it causing people to take U turn. It would be much better if we can re- arrange/modify the documents in a way to take out Z* things, traversal and all complex topics to 'Advance' section seperately. This is where Pyramid's multiple goals come into play. The BFG-ish users say that Traversal was immediately understandable to them and they could apply it right away, while they find URL Dispatch cumbersome. ZCML configuration was moved to the back of the manual for exactly the reason you describe, because it was a stumbling block for the large number of Pylons users who were about to come, and the BFG users knew where to find it in the back of the manual. I'd support moving Traversal to the back except I think there'd be more resistance to doing that than there was for ZCML. Traversal is central to an application if you're using it, whereas ZCML is just zis configuration format, y'know. [voice of Zaphod Beeblebrox's psychiatrist] There is no ZCML in the Pyramid docs anymore. It was all moved to the pyramid_zcml package docs, and in order to use ZCML, you must install that package. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
I'll be at the Pyramid sprint but I don't know what I'll be doing. I would like to learn Git and Pyramid-at-Github if somebody would like to do a mini crash course. On Fri, Mar 4, 2011 at 11:38 AM, Blaise Laflamme bla...@laflamme.org wrote: I'm up too On Mar 3, 8:09 pm, Carlos de la Guardia carlos.delaguar...@gmail.com wrote: Guys, I'll be at PyCon and would like to sprint on this. Maybe a tutorial with code. Anyone? -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde syr...@gmail.com wrote: On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr sluggos...@gmail.com wrote: I have a friend who is a marketer and supports the Pylons Project, but he's kind of gotten burned out on Python as a whole for various reasons so he can't quite be a full marketing advisor. Is there anyone else with marketing-type experience who would like to stand up? I'm generally a lurker, and am currently overwhelmed with other projects, but I do have some suggestions in this area and would be glad to help contribute to marketing efforts as time allows. Will you be at PyCon? There will undoubtedly be Pyramid/WSGI related Open Spaces every day at the conference; or at least there have been the past two years. So for those who can't attend the sprints, please stop by an open space and say hi. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 3:25 PM, Mike Orr sluggos...@gmail.com wrote: On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde syr...@gmail.com wrote: On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr sluggos...@gmail.com wrote: I have a friend who is a marketer and supports the Pylons Project, but he's kind of gotten burned out on Python as a whole for various reasons so he can't quite be a full marketing advisor. Is there anyone else with marketing-type experience who would like to stand up? I'm generally a lurker, and am currently overwhelmed with other projects, but I do have some suggestions in this area and would be glad to help contribute to marketing efforts as time allows. Will you be at PyCon? There will undoubtedly be Pyramid/WSGI related Open Spaces every day at the conference; or at least there have been the past two years. So for those who can't attend the sprints, please stop by an open space and say hi. Unfortunately, no, I didn't register for PyCon (although I am within driving distance). -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Well... same for me, I got a lot of clients work to complete and I've done my best trying to put everything in place to have something cohesive. I also got help from multiple people for different tasks and I'm grateful for every contribution. That said we definitely need to communicate the right message, provide the right level of documentation for the targeted audience, have a better way to expose tools and contributions, etc... I think we should add the website as a sprint project too, could be combined with the tutorial? Blaise On Mar 4, 2:50 pm, Mike Orr sluggos...@gmail.com wrote: Pylons never did marketing well for two reasons. One, the core developers aren't talented marketers. Two, we were busy finishing Pylons 1, and then we immediately finished Pyramid 1 back-to-back. That didn't leave much extra time for marketing or for focusing on the website. Now that Pyramid 1 is finished, we can take a step back and look at some areas we've neglected; e.g., marketing and tutorials. I say we, although in reality Ben is busy with his clients' sites, I'm plowing through three Pyramid add-ons, and for all I know Chris is working on his own clients' sites, and who knows what others are doing. Still, it's worth discussing how the Pylons Project as a whole can improve on marketing, documentation, and handholding (new users through the process of building their first site). I have a friend who is a marketer and supports the Pylons Project, but he's kind of gotten burned out on Python as a whole for various reasons so he can't quite be a full marketing advisor. Is there anyone else with marketing-type experience who would like to stand up? -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On 3/4/11 12:03 PM, Mike Orr wrote: I'll be at the Pyramid sprint but I don't know what I'll be doing. I would like to learn Git and Pyramid-at-Github if somebody would like to do a mini crash course. I'm no git guru, but I've been using it pretty heavily for the last 6 months and would be happy to give a tour of the basics to anyone who's interested. I'll be in ATL for all 3 days of the conference and the first 2 days of the sprint. -r -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
I would be +1 on splitting this up to pyramid_chameleon and pyramid_mako. But that's almost certainly because I have no use for either of those templating languages and for my specific work they sort of feel like bloating pyramid core. That being said, their presence doesn't cause any real problems for me... the only place where this could be detrimental that I could see is someone deploying on something like Google App Engine. - Rocky On Friday, March 4, 2011 2:09:30 PM UTC-3:30, Chris McDonough wrote: Of these, the only ones to very easily *not* install would be Mako, Chameleon, PasteScript, Paste, and PasteDeploy. The others are core dependencies that really can't very easily be externalized. Doing that would take us down to 13 dependencies. We could indeed make pyramid_chameleon and pyramid_mako and pyramid_paste packages to restore the functionality for users of those dependencies. Would that actually service any particular goal? Would having fewer rails in the core actually make anybody happier? -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote: That said we definitely need to communicate the right message, provide the right level of documentation for the targeted audience, have a better way to expose tools and contributions, etc... Who is the targeted audience? Currently it seems to be everyone with a complaint. I was very happy with repoze.bfg as it shipped and am very happy with pyramid as it currently ships. It was only a minor nuisance to add pyramid_zcml as a dependency to the projects I had using it. I subsequently stopped using it, so I don't have to manage another dependency; it is just spelling... I used to know the docs in and out pretty well. Now I no longer do, because things keep moving every time someone complains. Mostly I can find what I am looking for by searching, but not if it moves out of the core docs... If the same thing starts happening with pyramid's code/packages and it becomes a game of thimblerig I will be very disappointed. I suspect there is a silent majority out there that feels similarly. That is just a suspicion, however. There currently seem to be to disjoint desires: - make pyramid more opinionated with less ways to do things - make pyramid smaller and remove all dependencies I think that pyramid and bfg before it were clearly not trying to be either the kitchen sink or the micro-est of frameworks. I think it has also been well documented that higher level frameworks should be built on pyramid rather than into it. As for a smaller pyramid, for those embedded webapps... perhaps we should apply the same approach. Keep pyramid shipping with its current features and create a smaller core (say Prism) for it to depend on. Prism might not have any templating, paste or other undesirable and offensive packages, but could be used by people who need to conserve space. I wouldn't likely ever use it as I would want the things that currently ship with pyramid and am not worried about mako taking up 1MB of space unused. WRT the docs, perhaps we don't need to change (or rearrange) perfectly good reference materials every day. If we need introductory docs why not a second Intro to Pyramid doc? If we just want recipes to do basic things without too many options, could we appeal to people (particularly people frustrated with a recent experience) to add how-tos to the cookbook? Isn't that what it is for? The roof on this bike shed should definitely be tin. Cheers, ~ro -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, 2011-03-04 at 16:38 -0500, Reed L O'Brien wrote: On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote: That said we definitely need to communicate the right message, provide the right level of documentation for the targeted audience, have a better way to expose tools and contributions, etc... Who is the targeted audience? Currently it seems to be everyone with a complaint. I was very happy with repoze.bfg as it shipped and am very happy with pyramid as it currently ships. It was only a minor nuisance to add pyramid_zcml as a dependency to the projects I had using it. I subsequently stopped using it, so I don't have to manage another dependency; it is just spelling... I used to know the docs in and out pretty well. Now I no longer do, because things keep moving every time someone complains. Mostly I can find what I am looking for by searching, but not if it moves out of the core docs... If the same thing starts happening with pyramid's code/packages and it becomes a game of thimblerig I will be very disappointed. I suspect there is a silent majority out there that feels similarly. That is just a suspicion, however. There currently seem to be to disjoint desires: - make pyramid more opinionated with less ways to do things - make pyramid smaller and remove all dependencies I think that pyramid and bfg before it were clearly not trying to be either the kitchen sink or the micro-est of frameworks. I think it has also been well documented that higher level frameworks should be built on pyramid rather than into it. As for a smaller pyramid, for those embedded webapps... perhaps we should apply the same approach. Keep pyramid shipping with its current features and create a smaller core (say Prism) for it to depend on. Prism might not have any templating, paste or other undesirable and offensive packages, but could be used by people who need to conserve space. I wouldn't likely ever use it as I would want the things that currently ship with pyramid and am not worried about mako taking up 1MB of space unused. WRT the docs, perhaps we don't need to change (or rearrange) perfectly good reference materials every day. If we need introductory docs why not a second Intro to Pyramid doc? If we just want recipes to do basic things without too many options, could we appeal to people (particularly people frustrated with a recent experience) to add how-tos to the cookbook? Isn't that what it is for? The roof on this bike shed should definitely be tin. Cheers, ~ro I'm not averse to changing things in major releases, but we do need to recognize that major refactorings have a cost for both producers and consumers. All major docs work has historically been done by one person (me, or at least someone I've hired). The amount of time it took to write the software was long ago dwarfed by an order of magnitude the time it takes to write and maintain docs. Seemingly insignificant changes (from a developer perspective) to Pyramid can require hours of docs work if a feature is newly exposed or one is removed. I'm not complaining about this, it's just the way things are. On the consumer side, as Reed mentioned, it's very difficult to keep up when things change quickly. So, given that the costs are high, if we do make major functionality changes, I'd like it to be at the boundaries of first-dot major releases. For example, I don't think it makes sense to have a Pyramid 1.1 that does not ship with Mako or Chameleon or Paster, but nothing should be off the table for a 2.X. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
By that I meant, following a previous post I made, to possibly create new comer guides, opinionated guides, etc... to fill the missing gap. I don't think the current docs need to track down those requests, they are not perfect but they are great. Another point is complaint about pyramid needing more rails, and at the same time having less dependencies with a smaller core ;) We're in the middle :) On Mar 4, 4:38 pm, Reed L O'Brien reedobr...@gmail.com wrote: Who is the targeted audience? Currently it seems to be everyone with a complaint. I was very happy with repoze.bfg as it shipped and am very happy with pyramid as it currently ships. It was only a minor nuisance to add pyramid_zcml as a dependency to the projects I had using it. I subsequently stopped using it, so I don't have to manage another dependency; it is just spelling... -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Yeah like i said it's not a big deal for me, I would like it, but not doing it is obviously not preventing me from using pyramid to do some really cool stuff on GAE, and quickly. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Thu, 2011-03-03 at 03:54 -0800, Peter Alexis wrote: Just happened to see a blog about Pyramid, http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/ Sounds like (s)he is blowing off a little steam. All of these points are addressed in http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
I suggest to rename this thread Some trolls about Pyramid -- Gael On Thu, Mar 3, 2011 at 6:54 AM, Peter Alexis palexis2...@gmail.com wrote: Just happened to see a blog about Pyramid, http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/ -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote: Sounds like (s)he is blowing off a little steam. All of these points are addressed in http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . Indeed, my comment is awaiting moderation on the blog, I cited that URL as well. :) Cheers, Ben -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Thu, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote: Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet here. Sorry for the somewhat negative tone, as you can imagine, the post was written after spending several hours digging through a very large amount of the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. We've all been there, no worries. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Essentially what I am giving is a real world example of the concept of encapsulation, which is something that every programmer should value.* On Thu, Mar 3, 2011 at 12:43 PM, Joe Dallago jd.dall...@gmail.com wrote: I just thought that I would chime in and say that the dependency-heavy model that Pyramid uses is not a new one. Look at Linux, arguably the largest open source project in existence right now, it is hard to find a package that doesn't have 10 dependencies. Linux does this b/c it is efficient, and it means that code doesn't have to be duplicated. It is also important to note that it is also the model that Python excels at(easy imports, packages and module organization is easy, etc.). The dependency-heavy model actually makes learning more efficient in the long term as well, b/c if one module fails, then you don't have to ditch the whole system. For example(this example is somewhat from my experience with the cakephp framework), lets say you reach a point in an application where the framework itself is limiting your progress. Let's say that you need row-level permissions and the default auth helper doesn't do this. If the entire framework is tied together, then you would have to deal with either having to manipulate some of the source code(which could possibly be changed in future updates) or scrap the whole thing. With Pyramid, a failure in a specific module simply means you ditch that ONE module and sub in another. It is also important to note that if Pyramid itself becomes obsolete in 5-10 years, as Pylons did, then at least you can carry over your knowledge of SQLAlchemy, paster, deform, etc. to the next framework. Essentially what I giving a world world example of the concept of encapsulation, that is something that every programmer should value. On Thu, Mar 3, 2011 at 12:24 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote: Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet here. Sorry for the somewhat negative tone, as you can imagine, the post was written after spending several hours digging through a very large amount of the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. We've all been there, no worries. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Yeah, but encapsulation (a well-written API) and dependencies are totally orthogonal. One could write a dependency-less framework that provided sensible, minimal, yet functional components, and *still* provided a really clean API and way for developers to hook in external implementations. Lines like Pyramid only depends on 84 lines of repoze make me think: Okay, just pull in those 84 lines and ditch the dependency. But, the story isn't actually that simple, of course. (because repoze is the recommended default for tons of other stuff like auth/auth). I think Pyramid misses the mark providing a functional framework out of the box. In particular, the specifics around sessions and auth/auth. As a developer, you can't make a real site without good versions of both of these, and Pyramid only provides options and suggestions, not a solution here. I agree that learning outside modules is good practice, and can help you with other projects, but what most developers want is it works great out of the box, and I don't get stuck later on. I think Pyramid has the latter but not the former. Pyramid makes me feel shoe-horned into zope/repoze land. IUser, ISession, etc. Pyramid is missing the feel of a Consistent approach to X. where X pretty much any existing pluggable feature. What I'd like to see from a framework is good, internally consistent implementations of core features, and a nice clean API to plug alternates in. I feel like Pyramid is bending to the whims of outside implementations (zope, repoze, WebOb, etc) and providing APIs to match those, instead of going down the route of what's the right thing here. This development approach is clear from the design defense document. Steve s(he) Lacy On Thu, Mar 3, 2011 at 10:47 AM, Joe Dallago jd.dall...@gmail.com wrote: Essentially what I am giving is a real world example of the concept of encapsulation, which is something that every programmer should value.* On Thu, Mar 3, 2011 at 12:43 PM, Joe Dallago jd.dall...@gmail.com wrote: I just thought that I would chime in and say that the dependency-heavy model that Pyramid uses is not a new one. Look at Linux, arguably the largest open source project in existence right now, it is hard to find a package that doesn't have 10 dependencies. Linux does this b/c it is efficient, and it means that code doesn't have to be duplicated. It is also important to note that it is also the model that Python excels at(easy imports, packages and module organization is easy, etc.). The dependency-heavy model actually makes learning more efficient in the long term as well, b/c if one module fails, then you don't have to ditch the whole system. For example(this example is somewhat from my experience with the cakephp framework), lets say you reach a point in an application where the framework itself is limiting your progress. Let's say that you need row-level permissions and the default auth helper doesn't do this. If the entire framework is tied together, then you would have to deal with either having to manipulate some of the source code(which could possibly be changed in future updates) or scrap the whole thing. With Pyramid, a failure in a specific module simply means you ditch that ONE module and sub in another. It is also important to note that if Pyramid itself becomes obsolete in 5-10 years, as Pylons did, then at least you can carry over your knowledge of SQLAlchemy, paster, deform, etc. to the next framework. Essentially what I giving a world world example of the concept of encapsulation, that is something that every programmer should value. On Thu, Mar 3, 2011 at 12:24 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote: Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet here. Sorry for the somewhat negative tone, as you can imagine, the post was written after spending several hours digging through a very large amount of the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. We've all been there, no worries. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email
Re: Fwd: Some thoughts about Pyramid
On Thu, 2011-03-03 at 18:22 +, danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. While some of the things he points out are unfair and suggest unfamiliarity with certain aspects of the framework, there are some valid points in here as well: 1. The usage of traversal vs dispatch. It's unclear even to those quite familiar with Pyramid which to use for a given situation, and often I find myself yo-yoing between the two in the same project. Traversal is seen by some as the way to do Pyramid, with dispatch as an afterthought bolted on for Pylons compatibility, others still think the opposite especially with SQLAlchemy projects. This is very confusing for people who just want to get on and build something as it is so fundamental to the structure and design of your project. My personal rule of thumb: I use traversal when I use ZODB, routes when I don't. 2. Zopeisms, aka the ZCA, ZCML, zope.interface etc. This I see more of a marketing issue, but there is a valid concern here - the amount of conceptual overhead required to fully grok (pardon the pun) the framework is a problem. We often don't get to pick and choose the code we deal with as much of the time we have to deal with projects where we didn't have a hand in, so while I may prefer to ignore the ZCA for example in my own projects, I might well have to deal with it in someone else's. As with traversal/dispatch, the multi-paradigm approach may please nobody in the attempt to please everybody. Understood. I don't think we can really lump everything that starts with a Z into one category though. For example, ZCML is unrelated to ZCA and zope.interface. It's existence is an issue for some but we can't prevent or deter folks from using (and enjoying) ZCML any more than we can deter or prevent them from using and enjoying a bad library or application. The best we can do is not make it the default (which it isn't, so I don't expect folks to need to deal with a great many ZCML-based applications). The usage of ZCA internally in Pyramid is a separate issue. At this point, it seems gratuitous to break existing applications for the marginal benefit of reducing cognitive load for a minority of people who may one day need to deeply understand the Pyramid core. There are no requirements upon a Pyramid *application* developer (and never will be) to ever understand interfaces, components, etc. Even a Pyramid add-on developer needn't understand ZCA concepts. The only type of developer that truly will need to understand these things is a developer of the Pyramid core itself, and even then only in certain circumstances. I think this is an appropriate level of exposure, and I'm not sure that replacing ZCA with something else would make that any better. 3. The lots of tiny little components problem. Actually this is mostly unfair. Pyramid reuses existing stuff like WebOb and Paste, but it's not alone in this - the OP mentions Flask for example, which depends on Werkzeug and Jinja2. In this Django is unusual in having an in-house (or, more unkindly, NIH) approach to everything. Outside of Python, Rails 3 for example has moved more in the direction Pyramid is at with the merge of Merb. It makes sense when possible and practical not to reinvent the wheel - the problem for the Django developers was a lack of decent wheels half a decade ago, I'm sure they would not have taken the same approach today. That said, one trend that is the matter of some concern is spinning off of parts of the pyramid core - such as ZCML and handlers - into separate packages. This may reduce cohesion in the framework and lead to the tower of dependencies problem that TurboGears 2, for example, suffered greatly from. Not an immediate issue - and I've contradicted myself re: ZCML being part of the framework - but still a cause of concern. I don't really think we have a tower-of-dependencies problem, and I hope we avoid such a problem in the future. It's mostly just a matter of judgment I think. The code quality issue is bunk. I've found the Pyramid code remarkably easy to navigate and understand - try looking at some of the Django ORM/admin code in comparison. More importantly - as code quality is subjective - is the staggering number of unit tests. You may or may not agree with the design principles, but you can rely on the code you use. Yay! I don't really have any recommendations here or solutions to offer. All in all I do like Pyramid and appreciate its strengths more as I build more projects with it. It does however suffer from two things in particular: 1. A marketing problem. Django is for perfectionists with deadlines. Flask is the fun, easy microframework. What problem does Pyramid solve ? If you could summarize it in a single phrase, what would it be ? Pylons had a brilliant tagline - the Hacker's Framework. One thing Pyramid really needs is success stories - we used
Re: Some thoughts about Pyramid
On Thu, 2011-03-03 at 10:59 -0800, Stephen Lacy wrote: Yeah, but encapsulation (a well-written API) and dependencies are totally orthogonal. One could write a dependency-less framework that provided sensible, minimal, yet functional components, and *still* provided a really clean API and way for developers to hook in external implementations. That's fine, but the support and maintenance requirements become pretty massive. It's a great benefit, for example, to have someone-other-than-us maintaining Chameleon, Mako, and WebOb. If I personally had to maintain those things, they (and their users) would be a lot poorer for it. Lines like Pyramid only depends on 84 lines of repoze make me think: Okay, just pull in those 84 lines and ditch the dependency. The LRU code was indeed part of Pyramid at one point. But other packages also depend upon an LRU cache implementation, so pulling it out and sharing this code made sense. But, the story isn't actually that simple, of course. (because repoze is the recommended default for tons of other stuff like auth/auth). Actually it's not. Do you have a link to some documentation that makes this claim? I'd love to remove it if so. I think Pyramid misses the mark providing a functional framework out of the box. In particular, the specifics around sessions and auth/auth. As a developer, you can't make a real site without good versions of both of these, and Pyramid only provides options and suggestions, not a solution here. More specifics would be helpful. Do you mean docs-wise? It actually provides very concrete implementations (multiple ones) of each of these things. I agree that learning outside modules is good practice, and can help you with other projects, but what most developers want is it works great out of the box, and I don't get stuck later on. I think Pyramid has the latter but not the former. Pyramid makes me feel shoe-horned into zope/repoze land. IUser, ISession, etc. I'm going to suggest that learning how to create a Pyramid application by reading the Pyramid source code instead of reading its docs is a bit like learning how to drive by reassembling an engine. Knowing how to reassemble an engine is useful, but on a different level than just driving somewhere. Pyramid is missing the feel of a Consistent approach to X. where X pretty much any existing pluggable feature. What I'd like to see from a framework is good, internally consistent implementations of core features, and a nice clean API to plug alternates in. I feel like Pyramid is bending to the whims of outside implementations (zope, repoze, WebOb, etc) and providing APIs to match those, instead of going down the route of what's the right thing here. This development approach is clear from the design defense document. It sounds like you have very concrete opinions, and that you want to use a framework that provides these and only these opinions. That's fine, and you certainly have your choice of web frameworks, but please know that other folks actually use the features that fall outside of that set of opinions. For example, traversal: I would have exactly zero consulting income (at least if I wanted to use Pyramid) if I didn't have traversal, because most of our actual consulting engagements involve very hierarchical systems with very granular security constraints. Traversal makes this pattern very easy. I hope we've made it possible to ignore traversal, because it certainly doesn't make sense for every (or even most) applications, but its existence isn't for nothing. - C Steve s(he) Lacy On Thu, Mar 3, 2011 at 10:47 AM, Joe Dallago jd.dall...@gmail.com wrote: Essentially what I am giving is a real world example of the concept of encapsulation, which is something that every programmer should value.* On Thu, Mar 3, 2011 at 12:43 PM, Joe Dallago jd.dall...@gmail.com wrote: I just thought that I would chime in and say that the dependency-heavy model that Pyramid uses is not a new one. Look at Linux, arguably the largest open source project in existence right now, it is hard to find a package that doesn't have 10 dependencies. Linux does this b/c it is efficient, and it means that code doesn't have to be duplicated. It is also important to note that it is also the model that Python excels at(easy imports, packages and module organization is easy, etc.). The dependency-heavy model actually makes learning more efficient in the long term as well, b/c if one module fails, then you don't have to ditch the whole system. For example(this example is somewhat from my experience with the cakephp framework), lets say you reach a point in
Re: Some thoughts about Pyramid
On 3/3/11 10:59 AM, Stephen Lacy wrote: Yeah, but encapsulation (a well-written API) and dependencies are totally orthogonal. One could write a dependency-less framework that provided sensible, minimal, yet functional components, and *still* provided a really clean API and way for developers to hook in external implementations. Lines like Pyramid only depends on 84 lines of repoze make me think: Okay, just pull in those 84 lines and ditch the dependency. But, the story isn't actually that simple, of course. (because repoze is the recommended default for tons of other stuff like auth/auth). This is confusing to me. There is no single repoze thing. repoze is basically a brand name; it's a namespace package used for a collection of useful things developed mostly by Agendaless Consulting. Pyramid itself used to be repoze.bfg. There's no monolithic repoze thing that is being depended on. I think Pyramid misses the mark providing a functional framework out of the box. In particular, the specifics around sessions and auth/auth. As a developer, you can't make a real site without good versions of both of these, and Pyramid only provides options and suggestions, not a solution here. Pyramid is explicitly NOT making these decisions for you. That's what is meant when it's said that Pyramid is trying to be a relatively unopinionated framework. This is much less beginner-friendly than Django, nobody is denying that. But for some of us who are not beginners, we prefer being given choices, and choosing from available packages, rather than dealing w/ choices that the framework made that might not actually match what we really want. Eventually the hope is that there will be a more opinionated framework on top of Pyramid. This is one that would potentially compete with Django, one that would try to make the out-of-the-box experience much more complete. Pyramid is not that framework, and never intends to be. I agree that learning outside modules is good practice, and can help you with other projects, but what most developers want is it works great out of the box, and I don't get stuck later on. I think Pyramid has the latter but not the former. Pyramid makes me feel shoe-horned into zope/repoze land. IUser, ISession, etc. As I said, Pyramid is explicitly not trying to create an it works great out of the box experience. Not in the same way that Django and Rails are, anyway. It DOES work great out of the box for what it's trying to do, which is give developers a great deal of efficiency and flexibility in routing HTTP requests to callable code. If you want more rails to help you, Pyramid is not the best choice. As for feeling shoe-horned into zope/repoze land... I'm at a loss. Use of zope technologies is fairly minimal, and is entirely an implementation detail internal to Pyramid. You don't have to know anything about zope in order to use Pyramid. You're definitely not forced to use (or even understand) these idioms in order to build web apps w/ Pyramid. Pyramid is missing the feel of a Consistent approach to X. where X pretty much any existing pluggable feature. Again, this is explicitly the opposite of Pyramid's intent. What I'd like to see from a framework is good, internally consistent implementations of core features, and a nice clean API to plug alternates in. These desires are at cross-purposes, IMO. The more internally consistent your core features are, the less flexibly will you be able to plug alternates in. Alternate implementations of core technology often end up working very differently from each other, and what originally looked like internal consistency ends up looking like I can't do what I want to. In Django, for instance, it's technically possible to use an alternate ORM. When you do, you lose a lot of the other things that make Django valuable, though, and most Django users aren't willing to give up the other features. Pyramid goes the other route; there are clean APIs for plugging in alternate (template engine, persistence engine, security policy, etc. etc. etc.), but there is no pretense of a complete stack that is the default. I feel like Pyramid is bending to the whims of outside implementations (zope, repoze, WebOb, etc) and providing APIs to match those, instead of going down the route of what's the right thing here. This development approach is clear from the design defense document. I'd say that Pyramid is *using* (rather than bending to the whims of) lots of battle-hardened, pre-existing technology so it wouldn't have to reinvent the wheel a million times. And the answer to the question what's the right thing here? is an opinion. Once again, Pyramid is explicitly trying to not be opinionated. It doesn't always succeed... Pyramid definitely does have a few opinions, but it has many fewer than Django or Rails. If you want opinions, and you want choices to be made for you, Pyramid is probably
Re: Some thoughts about Pyramid
On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs to switch to a better library, and users have to adjust their applications. But overall we're glad that users and framework developers can switch libraries as they see fit, and that we can use the latest gee-whiz library as soon as it's available. The other main non-feature of Django is the tight binding between the ORM and the rest of the framework. That may work well for some Django applications, but it's just not something the Pylons Project believes in. The complexity of the Pyramid source is another issue. You're right that interfaces make the source more complex, and it's especially difficult for those who aren't accustomed to Python interfaces. (I can't keep track of Session vs ISession, or Settings vs ISomethingWithACompletelyDifferentName.) But that's a tradeoff we had to accept. One thing I remember fondly about Quixote is that I could read the entire printed source in half an hour and understand it.
Re: Some thoughts about Pyramid
So the thing we can carry away from this discussion is that we should improve Pyramid's new user experience, with tutorials and perhaps some defaults for basic functionality. On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs to switch to a better library, and users have to adjust their applications. But overall we're glad that users and framework developers can switch libraries as they see fit, and that we can use the latest gee-whiz library as soon as it's available. The other main non-feature of Django is the tight binding between the ORM and the rest of the framework. That may work well for some Django applications, but it's just not something the Pylons Project believes in. The complexity of the Pyramid source is another issue. You're right that interfaces make the source more complex, and it's especially
Re: Some thoughts about Pyramid
Hi :) Well, I'm pretty sure that the pylonsproject ecosystem would love to have more and more people who identifies with the ideas of the project. I mean, it doesn't need to be a 100% match, but there's have to have some. Seriously, just because you didn't feel at home it doesn't mean you can start bashing it. On the Zope inheritance subject. Well, repoze.BFG/Pyramid is what it is due to Zope. And most people who first came to it was attracted by that fact. One can definitely say that Zope2/3 is/was a huge and ambitious project trying to cover lots of different use-cases and they have succeeded. It turns out that the components that were used to achieve that were stuck in it and not reusable at all. It was something like you have in djando today. Want to use the django orm on a pyramid project? Just install django and use it! That's when the repoze project was needed. Those guys helped build Zope. They knew exactly what parts of it was worth exposing as plain reusable python components. And they were instrumental at doing that. Zope still hides a lot of nice features that only people with who know it intimately can go there and get back with something nice for people like you use it on your projects. So, had problems reading the code? Heh :) Go read Zope code ;) Or even Django because it suffers from the same evil... Traversal. There's not much to say here about it seriously. BFG/Pyramid allows one to write from very teeny tiny web-toys to huge user-driven deep intranets. Can't think of a huge system with thousands of url-mapped code. Just can't... Traversal solves that problem nicely. ZODB is great. You probably don't know what you are talking about here or probably hasn't worked on enterprisey intranets. Otherwise you'd notice ZODB is great. ZODB+Traversal is the perfect match. zope.interface. It's just one more problem that Zope solved but probably don't apply to you because you have no idea how to apply it. It's a very nice way to create extensible/pluggable software by creating layers. What do you suggest for that? entry points? So, are you sure Pyramid is for you? You know, you better check because Pyramid can do all that. -Fernando On Thu, Mar 3, 2011 at 2:39 PM, Stephen Lacy slacy+perso...@slacy.com wrote: Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet here. Sorry for the somewhat negative tone, as you can imagine, the post was written after spending several hours digging through a very large amount of the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. This is also after, early in my project, spending several weeks pouring over the state of code for both sessions and auth/auth. After looking at several solutions, including repoze.who (or is it repose.who v2) beaker, pyramid_beaker, etc. I found that there wasn't anything that really met my needs or worked the way I wanted. I ended up writing my own auth/auth and sessions systems for Pyramid, and amazingly, it's not that much code. I was puzzled why there were so many seemingly complex solutions to what at it's heart is actually some fairly straightforward code. I'll give a look at the design defense document, but I'm afraid that from a practical perspective, it's not really going to address some of the core issues. Granted, I'm coming from a Django background, and decided to explore Pyramid because of it's database-agnostic view (I'm using MongoDB). But, I've come to the conclusion that the plugin-centric view of the world has led to a dependency-laden and hard to understand code base, especially for a 1.0 product. I'm really sorry for the negative tone of that post, like I said it was written after a fairly large amount of frustrating code analysis, and that's just the mood I'm in. At the end of the day, Pyramid works, it powers my site, and has been quite stable and easy to work with... Steve On Thu, Mar 3, 2011 at 9:29 AM, Gael Pasgrimaud g...@gawel.org wrote: I suggest to rename this thread Some trolls about Pyramid -- Gael On Thu, Mar 3, 2011 at 6:54 AM, Peter Alexis palexis2...@gmail.com wrote: Just happened to see a blog about Pyramid, http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/ -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to
Re: Some thoughts about Pyramid
On Thu, Mar 3, 2011 at 23:27, Mike Orr sluggos...@gmail.com wrote: It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Hi Mike, thank you for taking care of new users The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. So true. It's exactly my mind when I read it for the first time. As new user, I don't care to know the multiple ways to create a site, I just want a right way (good practices, easy to maintain, etc). I want a good return of investment, not a deep knowledge of the framework. Anyway, I'm very impressed by the project, 1.0 come with a 800 reference manual and many other docs. -- Sebastien Douche sdou...@gmail.com Twitter: @sdouche (agile, lean, python, git, open source) -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
