Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting.
So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). - Igor On Wed, Dec 3, 2014 at 7:25 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > Choosing the right instrument for the job in an open source community > involves choosing technologies that the community is familiar/comfortable > with as well, as it will allow you access to a greater pool of developers. > > With that in mind then, I'd add: > Pro Pecan, blessed by the OpenStack community, con Flask, not. > > Kevin > ________________________________________ > From: Nikolay Markov [nmar...@mirantis.com] > Sent: Wednesday, December 03, 2014 9:00 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Fuel][Nailgun] Web framework > > I didn't participate in that discussion, but here are topics on Flask > cons from your link. I added some comments. > > - Cons > - db transactions a little trickier to manage, but possible # > what is trickier? Flask uses pure SQLalchemy or a very thin wrapper > - JSON built-in but not XML # the only one I agree with, but does > Pecan have it? > - some issues, not updated in a while # last commit was 3 days ago > - No Python 3 support # full Python 3 support fro a year or so already > - Not WebOb # can it even be considered as a con? > > I'm not trying to argue with you or community principles, I'm just > trying to choose the right instrument for the job. > > On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes <jaypi...@gmail.com> wrote: >> On 12/03/2014 10:53 AM, Nikolay Markov wrote: >>>> >>>> However, the OpenStack community is also about a shared set of tools, >>>> development methodologies, and common perspectives. >>> >>> >>> I completely agree with you, Jay, but the same principle may be >>> applied much wider. Why Openstack Community decided to use its own >>> unstable project instead of existing solution, which is widely used in >>> Python community? To avoid being a team player? Or, at least, why it's >>> recommended way even if it doesn't provide the same features other >>> frameworks have for a long time already? I mean, there is no doubt >>> everyone would use stable and technically advanced tool, but imposing >>> everyone to use it by force with a simple hope that it'll become >>> better from this is usually a bad approach. >> >> >> This conversation was had a long time ago, was thoroughly thought-out and >> discussed at prior summits and the ML: >> >> https://etherpad.openstack.org/p/grizzly-common-wsgi-frameworks >> https://etherpad.openstack.org/p/havana-common-wsgi >> >> I think it's unfair to suggest that the OpenStack community decided "to use >> its own unstable project instead of existing solution". >> >> >> Best, >> -jay >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackfirstname.lastname@example.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Best regards, > Nick Markov > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev