Ryan, can you please provide some more links on how these features what I described are implemented in Pecan? Some working examples, maybe? As far as I see now, each OpenStack project uses its own approach to integration with Pecan, so what will you recommend to look at?
On Thu, Dec 4, 2014 at 4:10 PM, Roman Prykhodchenko <rprikhodche...@mirantis.com> wrote: > I’d rather suggest doing in several iteration by replacing several resources > by Pecan’s implementations. > Doing that in one big patch-set will make reviewing very painful, so some bad > things might be not noticed. > > >> On 04 Dec 2014, at 14:01, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: >> >> 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 >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> -- >>> Best regards, >>> Nick Markov >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Nick Markov _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev