On Mon, Mar 14, 2011 at 12:37 PM, danjac...@gmail.com <danjac...@gmail.com> wrote: > Migration to Python 3 aside (which has to happen, sooner or later) my > concern here is that moving to Pyramid 2 so quickly is a bit premature > given the paint is barely dry on Pyramid 1.
We aren't moving quickly but just capturing people's ideas onto a list so that we can see if an architectural pattern emerges, so that we don't forget anything, and to disclose our potential long-term direction to both users and framework-makers (TurboGearsSuccessor, Khufu). We will have to choose GSOC tasks in a month or so, and we want to make sure they're consistent with our general direction so they don't turn into dead ends. A GSOC task will not be all of this, it would be one small part. It would also depend on what the student is interested in. The takeaway seems to be that PasteDeploy and PasteScript are not part of the permanent core but are "blessed" add-ons (formal dependencies), as Mako is. You can already configure a Pyramid app imperatively -- IN PYTHON -- by instantiating the app passing in the desired settings. This is hopefully emphasized in the Pyramid manual to a greater extent than is for Pylons; or at least that was the intention. The Paster templates with INI files are just a convenience to get you started. Paste* need a maintainer as Ian moves on to other things. That de facto falls to use because we use them most. The consensus seems to be that PasteDeploy and PasteScript could be cleaned up with their current active features rather easily, but Paste itself is more difficult, so it may be better to take what we need and leave the rest to die. So there are three different issues: moving Paste out of the Pyramid core, rewriting PasteDeploy/PasteScript with their current features (possibly merging them), and adding/moving to YAML This comes back to porting to Python 3 in that, how much effort do we want to put into porting the existing Paste* code to Python 3, if we're not sure we want to keep it long-term. > Should we not wait until there are some actual projects built with > Pyramid, and we get feedback from real world usage ? The danger is > that this ends up like TG2 - a continually moving target moving from > one dependency to the next, depending on what's flavour of the month, > with a small core of developers continually making changes but leaving > behind those who need a stable framework to work on. Reluctance noted. We do need more Pyramid applications and experience, and we don't want to be flightly like TurboGears has seemed. Perhaps we can just think about it for six months, and if there's anything somebody think is especially cool they can make an add-on for it. -- 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.
