On Sat, 2009-07-18 at 11:58 -0700, Mike Orr wrote: > On Fri, Jul 17, 2009 at 5:24 PM, Iain Duncan<[email protected]> wrote: > >> What we need now is people with marketing skills who are not > >> Pylons developers (thus not distracted by development). If you'd like > >> to do marketing, you can discuss your ideas here or on pylons-devel. > > > > I would be interested in doing some help in this area, but it's sort of > > contingent on how the whole cooperating with repoze/pypes stuff happens. > > If I can feel confident that working with Pylons and repoze is going to > > be a solid path forward for our company, I'm willing to pitch in there, > > but not so much if I'm not sure about the future. > > > > Sooo, it would be good for these sorts of things if more work was put > > into the public face of the future road map. On the last thread my last > > questions just never got answered.... :/ > > Pylons 1.0 and Pypes are two different frameworks. Pylons will remain > essentially as is, with some minor changes at the periphery. I've > listed them on the Roadmap (updated 6/26): > http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0 > The marketing issue is regarding that framework. > > Regarding Pypes, you must have seen Chris McDonough's message on the > pypefitters-discuss list this week. He released a prototype that runs > the Pylons QuickWiki demo and some BFG-like applications. Framework > front-ends (called "flavors") attach to Pypes via WebOb > Request/Response. I have not run the code yet but the description > looks promising. If enough Pypes users try the prototype and agree > this is the direction they want to go, the Pylons-ish flavor could be > completed.
I do plan to check that out, though at the moment I'm still working through the BFG docs. I am very interested in the idea of having something that supports both Pylons style and zope-traversal style as I'm know finding cases where zope-style-traversal is really handy. > > Regarding your questions and your company, forgive me for not > remembering which questions remain unanswered. You might want to > re-raise them in the original thread. I left off asking if the latest discussion about pypes from irc was posted anywhere after Ben referred to it, but got no answer. I guess my main beef with Pylons right now is that the developers could be making a lot more effort to keep their users in the know about what's going on behind the scenes with pylons. It makes a huge difference to users to know that development is somewhat transparent and that something is happening, even if it's clean up and bug fixes and docs and so on. > The main advantages of Pypes > over Pylons in my mind is an increasing ability to nest > mini-applications, greater modularity, and a move away from the magic > globals. (However, the Pylons-ish layer will reintroduce the globals > because they're an expected part of Pylons.) My thoughts exactly. =) > > So that gives you two potential paths. Remain with Pylons or > transition to Pypes when it's ready. My company has a few Pylons apps > in production and I've trained several developers in it, so even > though I personally like Pypes, we would not be able to transition to > it right away. The benefits would have to be weighed against the > burden of another major change. > > After Pylons 1.0, it will continue to be supported with bugfixes, but > there may be less enthusiasm to add features if Pypes is viable by > then. That is not necessarily bad because a "finished" framework > doesn't need changes; it just needs to sit there and be used. There > are no plans at this point that would necessitate a "Pylons 2.0". > > "If I can feel confident that working with Pylons and repoze is going > to be a solid path forward for our company" can be read in two ways. > (1) "I like Pylons as-is and I don't want the developers to abandon it > for some fancy new kid on the block.", or (2) "Pylons has significant > flaws that affect our company's ability to use it, and Pypes looks > like it will address these problems." If the fist is true, note that > the developers will have to support Pylons because they have apps > depending on it. I don't find anything wrong with Pylons, my concern is mostly that I don't want to see Pylons become another mochikit. It does what it was supposed to do, it's done, end-of-story. But if you are a small company selling services to using a framework, it's pretty important that it looks like the code you are selling isn't based on something that will be forgotten about down the road. The Pylons book is a huge boon in that regard, one of the major reasons I'm using Pylons as the 'house' for an ongoing piece of work for a university research centre is because I can say to them, 'buy the SQLAlchemy book, buy the Pylons book, if I get hit by a truck, you can find people to continue this project'. Having a published book to point them at gives a lot of legitimacy to a client, while a project that isn't moving forward conversely gives a bad impression even if it shouldn't. I am not saying I want Pylons to become Django on TG! I'm super impressed with the way it has a clear goal, is meeting that goal, and will be perceived as stable in that purpose. Thanks for the update. Iain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
