A month or two ago I started gathering differencies between Flask and Pecan, let's take a look at technical details. Maybe there are some things that are already fixed in current versions of Pecan, feel free to comment. https://docs.google.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov <nmar...@mirantis.com> 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. > > I personally would surely contribute to Pecan in case we decide to use > it and there will be some gaps and uncovered cases. I'm just curious, > does it worth it? > > On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes <jaypi...@gmail.com> wrote: >> On 12/03/2014 10:16 AM, Nikolay Markov wrote: >>> >>> It would be great to look at some obvious points where Pecan is better >>> than Flask despite of the fact that it's used by the community. I >>> still don't see a single and I don't think the principle "jump from >>> the cliff if everyone does" works well in such cases. >> >> >> This is part of why the Fuel development team is viewed as not working with >> the OpenStack community in many ways. The Fuel team is doing a remarkable >> job in changing previously-all-internal-to-Mirantis communication patterns >> to instead be on a transparent basis in the mailing lists and on IRC. I >> sincerely applaud the Fuel team for that. >> >> However, the OpenStack community is also about a shared set of tools, >> development methodologies, and common perspectives. It's expected that when >> you have an OpenStack REST API project, that you try to use the tools that >> the shared community uses, builds, and supports. Otherwise, you aren't being >> a team player. >> >> In the past, certain teams have chosen to use something other than Pecan due >> to technical reasons. For example, Zaqar's team chose to use the Falcon >> framework instead of the Pecan framework. Zaqar, like Swift, is a data API, >> not a control API, and raw performance is critical to the project's API >> endpoint). This is, incidentally, why the Swift team chose to use its swob >> framework over Webob (which Pecan uses). >> >> However, the reason that these were chosen was definitely not "it doesn't >> support the coding patterns I like". There's something that comes from being >> a team player. And one of those things is "going with the flow" when there >> isn't a real technical reason not to. All of us can and do find things we >> don't like about *all* of the projects that we work on. The difference >> between team players and non-team players is that team players strongly >> weigh their decisions and opinions based on what the team is doing and how >> the team can improve. >> >> Best, >> >> -jay >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Best regards, > Nick Markov -- Best regards, Nick Markov _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
