[openstack-dev] [Fuel][Nailgun] Web framework

Igor Kalnitsky ikalnitsky at mirantis.com
Thu Dec 4 13:01:31 UTC 2014


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.Fox at 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 [nmarkov at 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 <jaypipes at 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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Best regards,
> Nick Markov
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list