Pylons & repoze.bfg Merge
groups.google.com
Pylons & repoze.bfg Merge
1–10 of 35 posts
Re: Pylons & repoze.bfg Merge
#2As 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.
Re: Pylons & repoze.bfg Merge
#3As 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 kludg…
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.
Re: Pylons & repoze.bfg Merge
#4Glad 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?
Re: Pylons & repoze.bfg Merge
#5Glad 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?
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.
Re: Pylons & repoze.bfg Merge
#6Glad 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?
Yeah, I just got my company to go with Pylons 1.0. Wondering if I made a good choice.
Re: Pylons & repoze.bfg Merge
#7[deleted]
Re: Pylons & repoze.bfg Merge
#8That'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.
Re: Pylons & repoze.bfg Merge
#9As 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 kludg…
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 com…
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?
Re: Pylons & repoze.bfg Merge
#10As 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 kludg…
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 com…
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.