Re: Turbogears2 migration: custom error pages

On Tue, May 31, 2016 at 9:02 AM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > If the dotted notation is more common or a better strategy, we could > also just switch to it? > It has some advantages as all template paths are expressed in relation to python packages, so makes

Re: Turbogears2 migration: custom error pages

On Sun, May 29, 2016 at 9:19 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > > Currently, paster is still used. I briefly tried using gearbox (the > > supposed replacement) but it did not work. I did not spend more time > > on that to focus on the rest, but it should be

Re: Turbogears2 migration: custom error pages

On Mon, Jun 13, 2016 at 8:41 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Question is now: do you agree with this current split and shall I push > it to kallithea-tg, or do you prefer I make some changes first? > Sorry for taking so long to reply, pretty much overwhelmed

Re: Proposal for TurboGears2 port

On Tue, Feb 9, 2016 at 1:28 PM, Alessandro Molina < alessandro.mol...@gmail.com> wrote: > > I'll try to manage a proper routing solution instead of trying to fake > standard TG routing like I'm currently doing. > I wrote a much more robust dispatch solution that should now p

Re: Proposal for TurboGears2 port

On Mon, Feb 8, 2016 at 8:56 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > > If you have specific tasks that you want to offload, don't hesitate to > let me know. I can see if I have the knowledge to help with them. > Well, the knowledge I miss most is "what should kallithea

Re: Proposal for TurboGears2 port

On Thu, Jan 28, 2016 at 5:17 PM, Dominik Ruf wrote: > I gave it shot but failed :-( > > The first thing were the requirements. > Like you said I had to add some requirements to the setup.py. > "zope.interface" and "repoze.who" > But I don't understand why these are not

Re: Proposal for TurboGears2 port

On Fri, Jan 29, 2016 at 8:56 AM, Dominik Ruf wrote: > FYI a weird thing happend. > I pull your latest changes but still got the exception. > But after enabling debug in my development.ini the pages render correctly. Thanks, that pointed out the issue and I fixed it in

Re: Proposal for TurboGears2 port

>From the pure historical point of view Pyramid is the successor of Pylons officially, but technically is based on repoze.bfg framework and doesn't have much in common with Pylons from the point of view of APIs and design. It's a very flexible and powerful framework and I used it for a bunch of

Re: Proposal for TurboGears2 port

On Thu, Jan 28, 2016 at 12:34 AM, Mads Kiilerich 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

Re: Proposal for TurboGears2 port

On Thu, Jan 28, 2016 at 7:08 PM, Alessandro Molina < alessandro.mol...@gmail.com> wrote: > > As you can see here: http://blackhole.test.axantweb.com/KallitheaMovie.mp4 > on my environment most controllers are now working, looks like only > controllers related to changesets c

Re: Turbogears2 migration: test suite

On Fri, Feb 19, 2016 at 10:20 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Currently the test initialization code has > some pylons specifics which I don't understand (and thus fail to > convert to a Turbogears equivalent). > > Essentially, the setup code in TestController

Proposal for TurboGears2 port

Hi everyone, I'm Alessandro from TurboGears2 team. Before Christmas I got in touch with Mads and Andrew regarding the future of Kallithea and Pylons. As Pylons is now in legacy mode and won't see much support in future Kallithea would probably have to consider what to do in the near future. And

Re: Proposal for TurboGears2 port

On Tue, Jan 26, 2016 at 11:38 PM, Mads Kiilerich wrote: > Thanks, Alessandro. > > I'm very positive to the proposal. I would love if someone already had > done all the work or offered to do it. That would (probably) make it a > no-brainer to accept it and move in that

Re: Proposal for TurboGears2 port

On Mon, Feb 15, 2016 at 8:02 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > I've been reading the Turbogears documentation over the past days, and > will now dive in more into the code you made. > > conf['SQLASession'] = model.DBSession > AttributeError: 'module' object

Re: Turbogears2 migration: custom error pages

On Thu, Feb 18, 2016 at 12:05 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > Thanks, for basic 404 it indeed works. > However, I discovered at least one scenario where it does not: > Thanks for pointing that out. The reason is that when dispatching errors we do not pass

Re: Turbogears2 migration: test suite

lessandro, > > On Wed, Feb 24, 2016 at 2:38 PM, Alessandro Molina > <alessandro.mol...@gmail.com> wrote: > > > > > > On Fri, Feb 19, 2016 at 10:20 PM, Thomas De Schampheleire > > <patrickdeping...@gmail.com> wrote: > >> > >> Currently t

Re: Turbogears2 migration: test suite

On Wed, Mar 9, 2016 at 8:09 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > Then I get an error that seems to indicate that the model is not > correctly initialized. I suppose you are mentioning the "no such table: permissions" error. I faced that too. As I don't know much

Re: Turbogears2 migration: test suite

/kallithea/lib/utils.py?fileviewer=file-view-default#utils.py-717:732 On Mon, Mar 14, 2016 at 1:41 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Hi Alessandro, > > On Sun, Mar 13, 2016 at 10:10 PM, Alessandro Molina > <alessandro.mol...@gmail.com> wrote: > &g

Re: tgext.routes changes

On Sun, Apr 10, 2016 at 9:20 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Previously, using routes, we received a real POST request with > _method==PUT or _method==DELETE, while with Alessandro's change in > tgext.routes, we receive a real PUT or DELETE request, which is not

Re: turbogears migration: tests: internationalization

Reason is kallithea/model/forms.py using _() calls ( from tg.i18n import ugettext as _ ) Those translate the text the moment they are called, but as they are used in class attributes they actually get called the moment you import the module. As when you import the module there is no request in

Re: turbogears migration: tests: internationalization

On Mon, May 16, 2016 at 9:32 AM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > ../venv/kallithea-tg/lib/python2.7/site-packages/formencode/api.py:211: > in __classinit__ > cls._initialize_docstring() > ../venv/kallithea-tg/lib/python2.7/site-packages/formencode/api.py:302: >

Re: turbogears migration: tests: internationalization

Hi Thomas, did you manage to fix this be replacing "from tg.i18n import ugettext as _" with from "tg.i18n import lazy_ugettext as _" as suggested? I didn't have time to check but that should actually fix the issues you are facing. On Tue, Apr 26, 2016 at 9:34 A

Re: Turbogears2 migration: custom error pages

On Wed, Jun 29, 2016 at 9:31 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > I have pushed a rebased version to your kallithea-tg repo. I first > marked the existing changes as obsolete, but it seems this information > did not transfer to Bitbucket, don't know why (is your

Re: Turbogears2 migration: paging failures in changelog

On Tue, Jul 19, 2016 at 11:16 PM, Mads Kiilerich wrote: > > With debug=false, will tg / kallithea-tg also not send mails with > stacktraces? I have found that very convenient for fixing productions. > > I don't know if it makes sense that backlash is a mandatory dependency or

Re: Turbogears2 migration: paging failures in changelog

Sorry for late catching this, have you been able to have it working with those changes or still need me to have a look? I'll be at EuroPython this week, so if anyone is around feel free to get in touch! So we can work out any TG related issue. Bests, Alessandro On Mon, Jul 18, 2016 at 12:52 AM,

Re: Turbogears2 migration: import of helpers/app_globals into kallithea.lib

If I remember correctly kallithea explicitly handles commits, so probably it has no need for the transaction manager. Try to add base_config['tm.enabled'] = False in app_cfg.py and see it everything still works as expected and the error disappeared. Alessandro On Wed, Aug 31, 2016 at 2:15 PM,

Re: Turbogears2 migration: API calls

On Sat, Jul 30, 2016 at 10:01 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Hi, > > API calls currently do not work under Turbogears2. > > The simplest call is: > > ../venv/kallithea-tg-clean/bin/kallithea-api > --apikey=811a4ad6f382e75c20392b668cad9408bde9f42e >

Re: Turbogears2 migration: API calls

> > So the routing tries to access an index method. > > In the API code, the JSONRPCController parent class of ApiController > is supposed to direct the calls to the correct method, but it seems we > do not enter that class. > > JSONRPCController needs to be able to implement his own routing and

Re: Turbogears2 migration: API calls

On Mon, Aug 29, 2016 at 10:44 AM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > > > - Routing, Kallithea is probably the only TG2 app using routes as the > core > > dispatch system. This is probably not going away unless all controllers > are > > rewritten using

Re: Turbogears2 migration: API calls

On Mon, Aug 22, 2016 at 8:06 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Hi Alessandro, > > This is a gentle reminder in case you missed this mail, > Sorry, yep I missed that, have been a few superbusy months at work and I have been unable to follow open source projects as

Re: Turbogears2 migration: import of helpers/app_globals into kallithea.lib

< patrickdeping...@gmail.com> wrote: > On Sun, Sep 18, 2016 at 12:28 PM, Alessandro Molina > <alessandro.mol...@gmail.com> wrote: > > If I remember correctly kallithea explicitly handles commits, so > probably it > > has no need for the transaction manager. >

New TurboGears2 release

Just wanted to point out that version 2.3.11 of TurboGears has been released on PyPi. This should be a fully backward compatible release and no changes should be required in Kallithea. Full changelog is available at https://plus.google.com/+turbogears/posts/9DvMnoGhxny

Re: This Project has no future!

On Tue, Apr 10, 2018 at 10:04 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > > There is also an open point about the 'watch' feature and whether or > not it should be integrated in gearbox --reload rather than > introducing a new 'nodemon' mechanism. > The introduction of 'npm

Re: This Project has no future!

On Thu, Apr 12, 2018 at 10:52 PM, Thomas De Schampheleire < patrickdeping...@gmail.com> wrote: > Hi Alessandro, > > Thanks a lot for this information. > If I understood correctly you wouldn't even need npm at all, correct? > Yes, that's correct. npm nor node are required. Dukpy tries to replace