Proposal for TurboGears2 port

[Alessandro Molina]

On Thu, Jan 28, 2016 at 12:34 AM, Mads Kiilerich <mads at kiilerich.com> wrote:

>
> Do you have an idea of how much work it will be to make a full production
> ready migration?


Well, no :P
I think 90% will probably be ported in a bunch of days, the remaining 10%
will probably require to rewrite some parts. For example I saw that the API
controller pretty much overrides most of what was Pylons WSGIController and
works at pretty low level, that will probably have to be rewritten. Even
though it can probably be achieved in a day or two.


> Do you already now see any big tasks in the horizon?


Surely the routing should be ported from routes to turbogears routing.
Currently I just put one huge TG controller that intercepts everything and
then through routes dispatches requests to controllers it creates on the
fly and exposes their methods when requested. While we should mount all the
controllers as subcontrollers and @expose their templates instead of
manually calling render at the end of controllers. Also TG takes for
granted that controllers are singletons and never instanced twice, so
modifying a property of a controller introduces race conditions, custom
data should be stored in request object, while Kallithea stores things as
controller attributes pretty often.


> Now when you have looked more at our code base, in what areas do you think
> we could change our implementation to benefit more from TG ... and what
> benefits would that give us?
>

There are a lot of things that are custom written in Kallithea and that TG
provides out of the box, porting kallithea code to them would greatly
reduce code size and provide a standard implementation for people willing
to contribute. The main parts that came to my mind are:

- authentication (TG auth is based on top of repoze.who which if I'm
remember correctly was one of the targets of Kallithea to move to
repoze.who)
- authorization (TG provides predicates for authroization like
@require(not_anonymous()), @require(in_group('groupname')) and so on that
are currently custom implemented in Kallithea
- JSON based apis, TG has support for @expose('json') and
@decode_params('json') for controllers that have to receive and respond
json instead of manually encode/decode everything

Generally speaking TG is more high level than Pylons so probably many
things that are custom in kallithea are probably available in TG itself and
relying on the framework for those would greatly reduce the maintenance
effort but will require a greater porting effort :)


> /Mads
>
> PS: I guess we could make a migration look even more painless by
> temporarily introducing a mock pylons module that just call through to TG?


That's actually what I did at
https://bitbucket.org/_amol_/kallithea-tg/commits/3d03249816b8e0143e4cc7f8a4d955d561bd54a6#Lkallithea/config/app_cfg.pyT35
 to make webhelpers.pylonslib.secure_form work, I faked TG as the pylons
module so that it has been able to find pylons.session which is actually
identical to tg.session as both are Beaker sessions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20160128/c299b455/attachment.html>