Open Stack

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