7 ms·

Pylons & repoze.bfg Merge

78 points by ericflo 16y ago

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.
parfe 16y ago
Glad I ran across this. I was about to dive into pylons this weekend for a small project/learning experience. Had waited all this time for them to stabilize on 1.0 and get some of their documentation updated. Now I'd have to ask why would I bother?
- shazow 16y ago
  Pylons is still a great framework, and will be for the foreseeable future (a few years?). Just because it matured and reached its end-of-enhancements life, doesn't mean it's not useful. It will take a while for Pyramid to mature to this level.
- clutchski 16y ago
  Yeah, I just got my company to go with Pylons 1.0. Wondering if I made a good choice.
deleted 16y ago
[deleted]
old-gregg 16y ago
That's not merging - that's just killing Pylons. Ughh... The lesson for the future: when it comes to tech, stick with the leader. I didn't go Django route because it felt clunky and bloated compared to more elegant and flexible Pylons, but I guess it was a huge mistake. Pylons decided to "collapse" itself in favor of even more (!) elegance (like someone needed that), and a year worth of work is now based on something "in maintenance mode", while Django is still around. Tip: looking for a Python web framework? Django. Why? It will be there tomorrow.
- windle 16y ago
  I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months. Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things. The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just... Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-and-forking/ http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-... was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...
  - d0mine 16y ago
    Why Pyramid is not called Pylons 2?
    - windle 16y ago
      We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name. This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.
jacobian 16y ago
This looks like good news to me: I've noticed that Pylons and Repoze shared a lot of common ground. Ben and Chris are seriously smart dudes, and I'm excited to see what they come up with when they put their heads together. I am a bit surprised though by the way that this was done. As an outsider, it sounds to me like this decision was made among the lead developers of each framework privately, developed in private, and announced as a fait accompli. Was there really no step that involved consulting users of both frameworks to find out what they wanted? I ask because we (Django developers) spend a lot of time obsessing over backwards compatibility, often to the point where we have to compromises our grand goals for more pragmatic ones. I'd be terrified of making a move like this, so I'm curious to hear if users feel they've been slighted, or if they're pretty much happy to go with the flow.
- windle 16y ago
  Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components. Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configuration setup. It's code was also out there, and ppl poked at it some: http://bitbucket.org/chrism/marco http://bitbucket.org/chrism/marco It got a little ways, but it kept looking more and more like the existing repoze.bfg... which brought us to a point where pylons-trunk was built on BFG. This entire discussion is on the pylons-dev list here: http://groups.google.com/group/pylons-devel/browse_thread/thread/cf357889d81e37b3 http://groups.google.com/group/pylons-devel/browse_thread/th... Then, in an effort to resolve remaining differences in the code, several of us flew out to meet in person to discuss remaining issues in the code and see if a better collaboration could work out. We decided to try out the idea of a merger, since pylons-trunk for Pylons 2 was doing little more than minor extensions of repoze.bfg anyways, which was collapsed into the pyramid code-base (and is a distinction in that respect from repoze.bfg which doesn't have those bits). It worked out quite well from some attempts at 'trying it out' and the news of this leaked quite a bit earlier than we anticipated making it hard to try and put together what I think could've been a better process. Was there a discussion where we asked everyone in both communities for their input on merging? Not really, we talked to primary contributors and developers who had worked on each stack to try and solicit input and ensure they were all in favor of it. But yes, I agree entirely that I should've solicited feedback from the pylons community at large. For pylons the code-base, there really isn't going to be any difference from what there is right now, and has been. A maintained, stable, mature code-base, that has hit a point where there's little more to be done with it. It's been at a feature-standstill for about 2+ years now. It's not going away, and it will still be maintained. So I think the way the merger was done definitely could've been announced differently, with more emphasis on what it meant for the pylons code-base (nothing really), vs. the continuing development efforts of myself and other pylons developers. - Ben
jtchang 16y ago
If anyone happens to be in the bay area and is interested in a meetup to sit down and learn repoze.bfg and the differences between pylons let me know. I think it would helpful to get a bunch of us Pylons users together and talk about it.
- windle 16y ago
  I agree, I'm in the North Bay, and I'd be open to helping people work through pyramid, and discussing things in person. Would a meet-up next Thursday night (the 11th) work for some folks? Maybe around the South Bay or SF if someone can get some space?
rbp 16y ago
wow - no new features in the last 2 years. web2py seems to get a new feature every week even though they promise backwards compatibility.
- windle 16y ago
  I think you missed the bit about Pylons being a 'glue' framework between other packages. Those packages have gotten quite a few new features over the years, and they continue to get new features regardless of whether Pylons users use them. This is the kind of nice thing about using multiple open-source packages that are in heavy use throughout the Python world beyond just web frameworks (unlike web2py).

78 points by ericflo 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.

parfe 16y ago

Glad I ran across this. I was about to dive into pylons this weekend for a small project/learning experience. Had waited all this time for them to stabilize on 1.0 and get some of their documentation updated. Now I'd have to ask why would I bother?

shazow 16y ago
Pylons is still a great framework, and will be for the foreseeable future (a few years?). Just because it matured and reached its end-of-enhancements life, doesn't mean it's not useful. It will take a while for Pyramid to mature to this level.
clutchski 16y ago
Yeah, I just got my company to go with Pylons 1.0. Wondering if I made a good choice.

deleted 16y ago

[deleted]

old-gregg 16y ago

That's not merging - that's just killing Pylons. Ughh... The lesson for the future: when it comes to tech, stick with the leader. I didn't go Django route because it felt clunky and bloated compared to more elegant and flexible Pylons, but I guess it was a huge mistake. Pylons decided to "collapse" itself in favor of even more (!) elegance (like someone needed that), and a year worth of work is now based on something "in maintenance mode", while Django is still around. Tip: looking for a Python web framework? Django. Why? It will be there tomorrow.

windle 16y ago
I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months. Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things. The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just... Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-and-forking/ http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-... was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...
- d0mine 16y ago
  Why Pyramid is not called Pylons 2?
  - windle 16y ago
    We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name. This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.

jacobian 16y ago

This looks like good news to me: I've noticed that Pylons and Repoze shared a lot of common ground. Ben and Chris are seriously smart dudes, and I'm excited to see what they come up with when they put their heads together. I am a bit surprised though by the way that this was done. As an outsider, it sounds to me like this decision was made among the lead developers of each framework privately, developed in private, and announced as a fait accompli. Was there really no step that involved consulting users of both frameworks to find out what they wanted? I ask because we (Django developers) spend a lot of time obsessing over backwards compatibility, often to the point where we have to compromises our grand goals for more pragmatic ones. I'd be terrified of making a move like this, so I'm curious to hear if users feel they've been slighted, or if they're pretty much happy to go with the flow.

windle 16y ago
Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components. Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configuration setup. It's code was also out there, and ppl poked at it some: http://bitbucket.org/chrism/marco http://bitbucket.org/chrism/marco It got a little ways, but it kept looking more and more like the existing repoze.bfg... which brought us to a point where pylons-trunk was built on BFG. This entire discussion is on the pylons-dev list here: http://groups.google.com/group/pylons-devel/browse_thread/thread/cf357889d81e37b3 http://groups.google.com/group/pylons-devel/browse_thread/th... Then, in an effort to resolve remaining differences in the code, several of us flew out to meet in person to discuss remaining issues in the code and see if a better collaboration could work out. We decided to try out the idea of a merger, since pylons-trunk for Pylons 2 was doing little more than minor extensions of repoze.bfg anyways, which was collapsed into the pyramid code-base (and is a distinction in that respect from repoze.bfg which doesn't have those bits). It worked out quite well from some attempts at 'trying it out' and the news of this leaked quite a bit earlier than we anticipated making it hard to try and put together what I think could've been a better process. Was there a discussion where we asked everyone in both communities for their input on merging? Not really, we talked to primary contributors and developers who had worked on each stack to try and solicit input and ensure they were all in favor of it. But yes, I agree entirely that I should've solicited feedback from the pylons community at large. For pylons the code-base, there really isn't going to be any difference from what there is right now, and has been. A maintained, stable, mature code-base, that has hit a point where there's little more to be done with it. It's been at a feature-standstill for about 2+ years now. It's not going away, and it will still be maintained. So I think the way the merger was done definitely could've been announced differently, with more emphasis on what it meant for the pylons code-base (nothing really), vs. the continuing development efforts of myself and other pylons developers. - Ben

jtchang 16y ago

If anyone happens to be in the bay area and is interested in a meetup to sit down and learn repoze.bfg and the differences between pylons let me know. I think it would helpful to get a bunch of us Pylons users together and talk about it.

windle 16y ago
I agree, I'm in the North Bay, and I'd be open to helping people work through pyramid, and discussing things in person. Would a meet-up next Thursday night (the 11th) work for some folks? Maybe around the South Bay or SF if someone can get some space?

rbp 16y ago

wow - no new features in the last 2 years. web2py seems to get a new feature every week even though they promise backwards compatibility.

windle 16y ago
I think you missed the bit about Pylons being a 'glue' framework between other packages. Those packages have gotten quite a few new features over the years, and they continue to get new features regardless of whether Pylons users use them. This is the kind of nice thing about using multiple open-source packages that are in heavy use throughout the Python world beyond just web frameworks (unlike web2py).