Infinite Deployment Docs and OpenID Issues
Last update on .
Have spent rather a lot of time trying to wrestle the deployment docs into shape for the TurboGears 2.1 release. Even with all that work, only the "standard deployment pattern" is really in "good" shape. Alternative servers, alternative deployment styles, etceteras are all still needing lots of love. I am, however, I think, finished with that section for a while unless someone else chips in to help.
Also ran into one of those "argh" inducing issues this evening. A user was trying to follow through the "Using who.ini" discussion on his way to doing OpenID with TurboGears and ran into a weird, subtle bug. Turns out, when you disable TurboGears authentication repoze.what "fails open" as far as much TurboGears code is concerned. The predicates just all silently start evaluating to True. The @require() decorator thankfully does the right thing, but users who do:
Now always get a True value (the predicate object), so if you're using that to control display of information... oops. Not likely to have bitten too many users, but it just seems we should have something raising errors on __nonzero__() if the predicate's aren't "booleanized()".
In other news, given that someone else is trying to get OpenID working, I suppose I should look at the branch of repoze.openid. Upstream wants changes, but I haven't yet figured out what's supposed to happen wrt registration to make those changes work. Repoze just doesn't seem to have a registration story AFAICT.
Comments are closed.
Pingbacks are closed.
jacque on 03/10/2010 9:27 a.m. #
Turbo gear was though a long awaited release and people called it very nice but the small problems in it really made me sick, I think they should have taken some more time working on it!
Chris Perkins on 03/15/2010 4:33 p.m. #
A lot of the problems with TG stem from repoze.what. We are working on it. I've been collaborating with GothAlice from webcore to come up with a suitable solution that will be:
b) a single package.
Your feedback on this endeavor is of course always valuable. BTW, the comment above appears to be spam but I cannot tell.