Hi, Was attracted by Flask's 'micro' philosophy (as opposed to a 'framework'). Most contributions are plugins, rather than an expanding monolithic core (i.e. Django, Plone etc.). Will keeping the API generalizable always win over neat features? ALWAYS? What happens when someone makes "myFlask" (a dogmatic Flask distribution consisting of many plugins and helper code)? Should such a thing be disapproved of? Strikes me it should be. Apologies for being abstract. Cheers, Jim.
Hi, On 6/23/10 10:54 PM, JimG wrote: > Will keeping the API generalizable always win over neat features? We will do our best to keep the core API as flexible as necessary to support all interesting functionality as a Flask extension. > ALWAYS? What happens when someone makes "myFlask" (a dogmatic Flask > distribution consisting of many plugins and helper code)? I am very confident that the original project (for as long as there are active developers working on it, which I don't see a reason to doubt) will have a larger user base than a random fork. If a fork comes up that bundles Extensions and actually give something Flask itself with these extensions installed separately does not provide, we failed and have to improve. > Should such a thing be disapproved of? I would not approve a monolithic Flask package, but if someone sees good reasons why a fork of Flask (that distances itself from Flask) should not exist. We are living in a world where everyone is free to do whatever seems to be a good idea. And unlike certain other areas, we can't do much harm with mistakes :) Regards, Armin
> If [...] we failed and have to improve. I like the answer. Cheers, Jim. On 23 June 2010 22:16, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 6/23/10 10:54 PM, JimG wrote: > > Will keeping the API generalizable always win over neat features? > We will do our best to keep the core API as flexible as necessary to > support all interesting functionality as a Flask extension. > > > ALWAYS? What happens when someone makes "myFlask" (a dogmatic Flask > > distribution consisting of many plugins and helper code)? > I am very confident that the original project (for as long as there are > active developers working on it, which I don't see a reason to doubt) > will have a larger user base than a random fork. > > If a fork comes up that bundles Extensions and actually give something > Flask itself with these extensions installed separately does not > provide, we failed and have to improve. > > > Should such a thing be disapproved of? > I would not approve a monolithic Flask package, but if someone sees good > reasons why a fork of Flask (that distances itself from Flask) should > not exist. We are living in a world where everyone is free to do > whatever seems to be a good idea. And unlike certain other areas, we > can't do much harm with mistakes :) > > > Regards, > Armin >
For 'generalizable' I should have put 'general-purpose'. Cheers, Jim. On 23 June 2010 21:54, JimG <j.gumbley@gmail.com> wrote: > Hi, > > Was attracted by Flask's 'micro' philosophy (as opposed to a 'framework'). > > Most contributions are plugins, rather than an expanding monolithic core > (i.e. Django, Plone etc.). > > Will keeping the API generalizable always win over neat features? > ALWAYS? What happens when someone makes "myFlask" (a dogmatic Flask > distribution consisting of many plugins and helper code)? Should such a > thing be disapproved of? Strikes me it should be. > > Apologies for being abstract. > > Cheers, Jim. >