Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pylons & repoze.bfg Merge

groups.google.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Pylons & repoze.bfg Merge

#11

Post by windle »

old-gregg wrote: post #8

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…

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...

Finding a path forward for extensibility that didn't hit this forking problem: 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...

Re: Pylons & repoze.bfg Merge

#12

Post by windle »

old-gregg wrote: post #10
windle wrote: post #3

Earlier quoted context omitted.

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 clas…

Sorry you didn't see it, I'll try again: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

Re: Pylons & repoze.bfg Merge

#13

Post by windle »

d0m wrote: post #9
windle wrote: post #3

Earlier quoted context omitted.

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?

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...

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.

Re: Pylons & repoze.bfg Merge

#14

Post by zzzeek »

old-gregg wrote: post #8

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…

This is not at all an apt comparison. With Django, you're buying into its templating, routing system, its ORM, its view/controller paradigm, its central app configuration, its core request delivery system, whatever it does for caching/sessions, and all the admin stuff. With Pylons, you've bought into some choice of templating (usually Mako), routing system (Routes), some choice of ORM (usually SQLAlchemy), its view/controller paradigm, its central app configuration, its core request delivery system (Paste, PasteScript, etc.), caching/sessions (Beaker), and it doesn't come with any admin stuff.

Pylons' change to Pyramid most certainly does not replace that whole stack. It replaces exactly two of those components, the view/controller paradigm and central app configuration. All the things that don't change at all are: templating, ORM, routing, Paste/Pastescript, caching/sessions still on Beaker.

So this nothing at all like moving to an entirely new framework, Mako/SQLAlchemy/Beaker aren't going anywhere.

edit: the routing changes a bit, but its an improved and higher performing package with mostly complete feature parity. I'm looking forward to using it.

Re: Pylons & repoze.bfg Merge

#15

Post by Keith83 »

windle wrote: post #13
d0m wrote: post #9

Earlier quoted context omitted.

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?

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... If your a…

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 :)

Re: Pylons & repoze.bfg Merge

#16

Post by old-gregg »

windle wrote: post #12
old-gregg wrote: post #10

Earlier quoted context omitted.

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 clas…

Sorry you didn't see it, I'll try again: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

:-) I guess I'll have to copy&paste to support my argument. A link isn't good enough:

Due to the use of sub-classing, extensive, sometimes confusing, use of Stacked Object Proxy globals, and issues with configuration organization

As an active Pylons user I never, ever heard of these issues in Pylons circles. Translation: nobody asked for these improvements. Statements like "sometimes confusing" aren't doing it. When? Confusing for whom? I, for one, loved stacked globals. "from pylons import config" was great. Rails wasn't that simple. This is a big shock coming from nowhere. It just wasn't something that came up often on Pylons mailing list.

Let me make this clear: do I believe Pylons could be better? Yes I do. Do I think killing it to make it better was a good idea? No, I don't.

Anyway, I have tremendous respect for Ben and can't blame him for getting bored and wanting to work on something different.

EDIT: I just realized that you may be Ben. In that case thanks for building the greatest web framework for my favorite language! The fact that I'm passionate enough to bitch and moan about its death on the Internet should be the best testament to its greatness! :)

Re: Pylons & repoze.bfg Merge

#17

Post by jacobian »

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.

Re: Pylons & repoze.bfg Merge

#18

Post by [deleted] »

windle wrote: post #12
old-gregg wrote: post #10

Earlier quoted context omitted.

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 clas…

Sorry you didn't see it, I'll try again: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

[deleted]

Re: Pylons & repoze.bfg Merge

#19

Post by windle »

old-gregg wrote: post #16
windle wrote: post #12

Earlier quoted context omitted.

Sorry you didn't see it, I'll try again: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

:-) I guess I'll have to copy&paste to support my argument. A link isn't good enough: Due to the use of sub-classing, extensive, sometimes confusing, use of Stacked Object Proxy globals, and issues with configuration organization As an active Pylons user I never, ever heard of these issues in Pylons circles. Translation: nobody asked for these improvements. Statements like "sometimes confusing" aren't doing it. When?…

Many people loved "from pylons import config", until it didn't work, which frequently happened anytime someone wanted to use something from a Pylons app in a command line script (which seems to be pretty often). I do have a few minor clean-ups that help slightly with that stuff which I'll likely put out a Pylons 1.0.1 to address.

> Let me make this clear: do I believe Pylons could be better? Yes I do. Do I think killing it to make it better was a good idea? No, I don't.

So, the whole 'killing' thing seems slightly extreme. I've maintained Pylons with few changes besides bug fixes, security fixes, and deprecating old things for the past several years. And now the announcement that I don't plan on doing any more than the same thing for the pylons package code-base is "killing it off"?

If you're happy with pylons, there's no need to stop using it. The docs will always be available for it, the code-base will not be removed. By design, I just couldn't see how to continue it forward in ways that I (and a lot of people I've talked with) need.

Of course, a lot of people may not need anything more than pylons provides right now, and in that case I'd be hard pressed to tell them to switch their code to use pyramid. pylons is stable, mature, and has been maintained as such for quite awhile, there's a book that still pretty much applies to 1.0.

> Anyway, I have tremendous respect for Ben and can't blame him for getting bored and wanting to work on something different.

Thanks, sorry my nick doesn't reflect it, this is Ben. Seems I can't change my profile info on ycombinator, sigh. Or that 'feature' doesn't exist, anyways...

As I mentioned, the Pylons code-base was essentially frozen for any direction forward which I needed to build higher level tools. I know this may not be immediately obvious to everyone depending on your requirements, and pylons suits many peoples needs perfectly well.

I will be blogging about this in the future, at which point some of the key differences, and what they enable will hopefully become more clear. But Pylons is definitely not dead, and I think it won't be too long before people start to see what a larger development team can do. :)

Re: Pylons & repoze.bfg Merge

#20

Post by windle »

jacobian wrote: post #17

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, a…

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

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/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

Post reply on HN