Nikolay, I'd recommend taking a look at the work I did for the Barbican project in converting their falcon-based API to pecan:
https://review.openstack.org/#/c/89746 ...because it makes use of a pecan feature called "generic controllers" for defining RESTful interfaces: https://review.openstack.org/#/c/138887/ The approach that most people in the OpenStack community have taken (probably because Ceilometer did so first, and provided a canonical implementation), the use of `pecan.rest.RestController`, is something we added to pecan to support compatability with TurboGears2. In my opinion, RestController is quite confusing, and overkill for what most APIs need - I recommend that people *not* use RestController due to its complexity, which mainly stems from TG2 compatability). I'm also working today on improving pecan's documentation as a result of some of the questions I've seen floating around in this thread. On 12/04/14 06:32 PM, Nikolay Markov wrote: > 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 -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev