5 ms·

As someone who's spent thousands of hours on our current Pylons codebase, I'm very interested in knowing how difficult it'll be to move my now-legacy Pylons 1.0

by codypo 16y ago

As someone who's spent thousands of hours on our current Pylons codebase, I'm very interested in knowing how difficult it'll be to move my now-legacy Pylons 1.0 apps to the new Pyramid framework. They don't make mention of that. They do say that Pylons 1.0 apps will run within the Pyramid framework through a fallback handler to an existing Pyons app, so we're not hopelessly screwed, but that does sound a little kludgey. A larger concern of mine is, given the enormous amounts of time and money we've spent on developing for Pylons, why would I port over to Pyramid? Why wouldn't I just port over to a more stable web framework, less likely to deprecate the technology on which our entire business is based? It definitely sounds like a neat framework, but I don't see as much value in neat technology when it shows a disturbing tendency to pull the rug out from under me.

windle 16y ago
To answer your first question, it won't be nearly as easy of a transition as it was from Pylons 0.9.7 to 1.0. For some reason, the fact that Pylons 1.0 hasn't had any updates or feature additions in the 6+ months hasn't seemed to be an issue, it was already mostly in a "it works as well as it can work" stage. Plugging in the old Pylons app using WSGI isn't really any more kludgey than using WSGI for any other app composition use, which is plentiful. For the second question, the best reason would be that in the world of web development, all web frameworks will deprecate old technology. It's the only way to move forward if a fundamental design decision in the core needs to be re-architected. I know many former TurboGears users may have a lot of angst about this, because the rug has been pulled out a bit more than for Pylons users, who have rarely had to deal with everything at the bottom being replaced. This direction was taken to help avoid that again in the future, because now all the development for everything... top to bottom... we have under one roof so to speak. In pyramid we have a core that is architected to deal with the extensibility issue, and can pick up development of features that the Pylons 1.0 code-base couldn't handle. Since its based on over 2 years of development and use in the repoze.bfg community, it means its very solid and stable already. In short, I think it's on track to be one of the most stable Python web frameworks out there, just like Pylons 1.0 and prior has been quite stable. My advice would be to try new, small experiments and projects with it first. I'll be publishing more articles highlighting the improvements and extra features it brings to the table soon.
- d0m 16y ago
  For a new startup, would you honestly recommend going with pyramid? And what about Django.. do you think it'll go faster to prototype and develop with pyramid?
  - windle 16y ago
    Depending on what you're prototyping, it could very well be done faster with Django. Django provides a bunch of 'generic views' which can make tossing up lists of objects from the db very fast to get started with. Then usually you end up fully replacing it all later, but it gives you a good start. My views haven't changed since I answered this: http://stackoverflow.com/questions/48681/pros-cons-of-django-vs-pylons http://stackoverflow.com/questions/48681/pros-cons-of-django... If your app doesn't clearly fit into the sweet-spot's for Django, the argument will be less compelling. The pyramid code-base does have a lot of maturity behind it, it's not completely brand-new, so I don't think it'd be a problem to develop against it to be able to utilize its additional extension points.
    - Keith83 16y ago
      To help make the move from Pylons, I'd love to see a document introducing Pyramid from a Pylons perspective and explaining what it does differently. Please say Pyramid has a debug mode like Pylons :)
      - cd34 16y ago
        easy_install weberror, tempita, pygments add egg:WebError#evalerror into your pipeline. It isn't in the default Pyramid paster template, but, it was mentioned that it will probably be included in in the default Pyramid paster templates. http://goo.gl/EDqNo http://goo.gl/EDqNo is a document I wrote regarding the transition of a Pylons 1.0 to Pyramid 1.0a1 application.
- old-gregg 16y ago
  What bothers me is that nowhere in that email, or nowhere on the site, I see a single reason for this move. Why? Why do it? The only explanation I see is that developers wanted a nicer codebase. I've been on Pylons mailing list forever, and I can't recall a single practical issue or a feature request, which was decided to be hard/impossible to do due to architecture limitations. It just never comes up. This is a classic case of redesign for the sake of redesign.

by codypo 16y ago

windle 16y ago

To answer your first question, it won't be nearly as easy of a transition as it was from Pylons 0.9.7 to 1.0. For some reason, the fact that Pylons 1.0 hasn't had any updates or feature additions in the 6+ months hasn't seemed to be an issue, it was already mostly in a "it works as well as it can work" stage. Plugging in the old Pylons app using WSGI isn't really any more kludgey than using WSGI for any other app composition use, which is plentiful. For the second question, the best reason would be that in the world of web development, all web frameworks will deprecate old technology. It's the only way to move forward if a fundamental design decision in the core needs to be re-architected. I know many former TurboGears users may have a lot of angst about this, because the rug has been pulled out a bit more than for Pylons users, who have rarely had to deal with everything at the bottom being replaced. This direction was taken to help avoid that again in the future, because now all the development for everything... top to bottom... we have under one roof so to speak. In pyramid we have a core that is architected to deal with the extensibility issue, and can pick up development of features that the Pylons 1.0 code-base couldn't handle. Since its based on over 2 years of development and use in the repoze.bfg community, it means its very solid and stable already. In short, I think it's on track to be one of the most stable Python web frameworks out there, just like Pylons 1.0 and prior has been quite stable. My advice would be to try new, small experiments and projects with it first. I'll be publishing more articles highlighting the improvements and extra features it brings to the table soon.

d0m 16y ago
For a new startup, would you honestly recommend going with pyramid? And what about Django.. do you think it'll go faster to prototype and develop with pyramid?
- windle 16y ago
  Depending on what you're prototyping, it could very well be done faster with Django. Django provides a bunch of 'generic views' which can make tossing up lists of objects from the db very fast to get started with. Then usually you end up fully replacing it all later, but it gives you a good start. My views haven't changed since I answered this: http://stackoverflow.com/questions/48681/pros-cons-of-django-vs-pylons http://stackoverflow.com/questions/48681/pros-cons-of-django... If your app doesn't clearly fit into the sweet-spot's for Django, the argument will be less compelling. The pyramid code-base does have a lot of maturity behind it, it's not completely brand-new, so I don't think it'd be a problem to develop against it to be able to utilize its additional extension points.
  - Keith83 16y ago
    To help make the move from Pylons, I'd love to see a document introducing Pyramid from a Pylons perspective and explaining what it does differently. Please say Pyramid has a debug mode like Pylons :)
    - cd34 16y ago
      easy_install weberror, tempita, pygments add egg:WebError#evalerror into your pipeline. It isn't in the default Pyramid paster template, but, it was mentioned that it will probably be included in in the default Pyramid paster templates. http://goo.gl/EDqNo http://goo.gl/EDqNo is a document I wrote regarding the transition of a Pylons 1.0 to Pyramid 1.0a1 application.
old-gregg 16y ago
What bothers me is that nowhere in that email, or nowhere on the site, I see a single reason for this move. Why? Why do it? The only explanation I see is that developers wanted a nicer codebase. I've been on Pylons mailing list forever, and I can't recall a single practical issue or a feature request, which was decided to be hard/impossible to do due to architecture limitations. It just never comes up. This is a classic case of redesign for the sake of redesign.