[08:49] *** now talking in #turbogears
[08:49] *** topic is TurboGears: http://www.turbogears.org | Paste bin: http://paste.turbogears.org | IRC Log: http://irclog.turbogears.org | TurboGears 1.0.2.2 is out. get it while it's hot
[08:49] *** set by elvelind on Tue May 08 09:28:14 2007
[08:49] *** channel #turbogears mode is +tnc 
[08:49] *** channel created at Sat Nov 25 22:42:40 2006
[08:49] <mramm> removing cherrypy references isn't the goal at all
[08:49] <mramm> It's just that we cp3 changed thngs so that we can't run tests the same way.
[08:51] <mramm> fu_man_chu:  I have a question for you if you have time...
[08:54] <mramm> alberto posted this example code: http://paste.turbogears.org/paste/1324  which doesn't work as he expected it to becasue cp3 uses SCRIPT_NAME rather than PATH_INFO as the key in the config.   I assume that there's a reason behind the diff between the way the tree works and the way that alberto expected it to work.
[08:56] <chrismiles> ok I meant remove some cherrypy references, such as referring to cherrypy.resonse (although albertov will add some backwards compatibility for that, it won't be recommended)
[08:56] <albertov> chrismiles: A port of the controller_tests to the new interface would be great and appreciated (since that, eventually, is the way to go) however, I'll try to make the former tests work with as little change as possible just to make sure we can emulate the old API so migration of other apps is easier (how on earth would you trust that your 1.0 app works in 1.1 if most of your controller tests break?? :)
[08:56] <mramm> Yea, that makes sense
[08:57] <mramm> It will also be good to have the new tests as an example of the new interface.
[08:58] <chrismiles> that's what I am working on, a port of controller_tests to work with fixture.  if that's not useful, certainly say so and I'll tackle something more worthwhile.
[08:58] <albertov> chrismiles: Ths might help: http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/templates/default_project/%2Bpackage%2B/tests/__init__.py_tmpl
[08:58] <albertov> that's how pylons initializes the TestApp in the base TestCase for controller tests....
[08:59] <albertov> chrismiles: we could even subclass TestApp in TG to provide some goodies in the future (BrowserSession, etc...)
[09:00] <albertov> brb
[09:01] <chrismiles> albertov: good idea
[09:02] *** alakdan quit ("its time to get L.... errr Paid")
[09:02] <fu_man_chu> ok I'm awake now, reading backchat
[09:03] <albertov> fu_man_chu: Hi Robert!
[09:03] <fu_man_chu> howdy!
[09:03] <albertov> fu_man_chu: I think mark was referring to http://paste.turbogears.org/paste/1323
[09:03] <fu_man_chu> ah :) that's better
[09:04] <albertov> fu_man_chu: I expected /tree2/ and /tree2/sub to behave the same as / and /sub but they're not...
[09:04] <mramm> Oops.  Sorry about the link mixup.
[09:05] * fu_man_chu looks at paste.urlmap a bit
[09:06] <fu_man_chu> ok, but I'm confused--cherrypy.Tree is basically paste.urlmap, so why use both? pick one or the other
[09:07] <albertov> fu_man_chu: mounting the apps with cp._cptree.Application (setting script_name to None) works fine however (I remember some talk about this at... cp ticket #56 i believe)
[09:08] <fu_man_chu> right, by setting script_name to None, it should pick up the script_name from the WSGI environ
[09:08] <albertov> fu_man_chu: #56'?? where's my brain today.... ;) #638 is
[09:09] *** timphnode (n=tim@69.155.106.201) joined
[09:09] <albertov> fu_man_chu: but, why doesn't Tree behave similarily?
[09:13] <fu_man_chu> I think it's because cherrypy.Tree uses environ.get('SCRIPT_NAME', '') + environ.get('PATH_INFO', '') to match a key in its "apps" dict
[09:13] *** hatul30 (i=ariel@gateway/tor/x-61e764dd4b51c063) joined
[09:14] <albertov> fu_man_chu: why not just PATH_INFO? (I'm sure I'm missing something somewhere...)
[09:15] <fu_man_chu> phone
[09:19] <albertov> fu_man_chu: just read "...cherrypy.Tree is basically paste.urlmap, so why use both?..." (\me irc noob): Me might just go with URLMap + Application, however, maybe using Tree would be more familiar to 1.0 users since tree is also used there... anyway, it's not much of a problem either... just curious....
[09:24] *** timphnode_ quit (Read error: 110 (Connection timed out))
[09:28] <fu_man_chu> URLMap + Application should be fine
[09:29] <albertov> ok
[09:30] <fu_man_chu> cherrypy.Tree doesn't really allow for n-level dispatch graphs--it assumes you're only dispatching on URL once
[09:31] <albertov> i see...
[09:31] <fu_man_chu> that could be fixed in a future version, but it would be a serious compatibility issue
[09:31] <fu_man_chu> good thing there are alternatives :)
[09:35] <mramm> Well, I gotta go handle a couple of things offline.   Be back in a few.
[09:36] <mramm> BTW, Thanks Robert.
[09:36] <fu_man_chu> np
[09:38] <albertov> fu_man_chu: See if I got this right... the dict at ["/"] that an Application receives propagates to all subpaths, right? is there any other key where config is merged from?
[09:38] *** tazzzzz (n=tazzzzz@c-68-40-243-29.hsd1.mi.comcast.net) joined
[09:38] *** tazzzzz quit (Client Quit)
[09:38] <fu_man_chu> well, cherrypy.request.config = global config + App config
[09:39] <fu_man_chu> (all flattened down into a single 1-level dict of entries appropriate for the current PATH_INFO)
[09:40] <fu_man_chu> and don't forget cp_config attached to handlers and controllers
[09:42] <albertov> fu_man_chu: hmmm, and what happens with  config updates to cherrypy.config (not the dict passed to Application), do they get merged somehow into every app's
[09:42] <albertov> ?
[09:43] <fu_man_chu> global config doesn't get merged into the actual app.config, but each request.config collects from both global and app config
[09:44] <fu_man_chu> see http://www.cherrypy.org/browser/branches/cherrypy-3.0.x/cherrypy/_cpdispatch.py#L128
[09:44] <albertov> fu_man_chu: cool, then I think using paste.config is probabbly being overkill and we can do with just cherrypy.config (which will be simpler and less error-prone I believe...). I was worried because TG (and TG apps) do lots of config read/writes at import time...
[09:45] <fu_man_chu> simple is nice :)
[09:45] <fu_man_chu> ?? at *import* time? that seems...too early
[09:45] <albertov> albertov: ... we should probably be changing that now that we're aiming for various apps to cohabitate the same process, but I'ts nice to have a fallback for legacy code....
[09:46] <albertov> alberov: yea, I know... but we're too used to single apps per process... :) see, start-myapp.py *first* updates config, then imports Root...
[09:47] <nbm> albertov: Can I make identity store identity and so forth in environ instead of on the request?
[09:48] <albertov> alberov: ideally all config should be passed as a parameter to the app_factory and be read from there... but it'll be tricky since config is being read even inside the "expose" entangler...
[09:48] <albertov> albertov: we're talking about 1.1 right?
[09:48] <albertov> cool, I'm talking to myself.... :) I meant nbm
[09:49] <fu_man_chu> albertov, you don't have to start every IRC message with your own name :)
[09:49] <albertov> \me can't hide his IRC newbieness... ;)
[09:49] <fu_man_chu> is start-myapp.py auto-generated (and if so, where)?
[09:49] <nbm> albertov: Yeah - I noticed identity wasn't working.  Choice between a Tool and Middleware.  And since we're looking at Authkit later anyway...
[09:50] <albertov> yep, and installed at /usr/bin... that should change to use paster + the app factory... will be much simpler
[09:51] <albertov> nbm: I would use AuthKit for authentication and simplify identity to just handle authorization, identity could remain as a filter/tool or ported to middleware... whatever however wants to port it decides... :)
[09:53] <fu_man_chu> or both
[10:01] <chrismiles> is correct way to set a response header in a controller method still: cherrypy.response.headers["Content-Type"] = "text/html"  ? (in 1.1)
[10:03] <albertov> fu_man_chu: regarding the config issue... now I remember why I used paste.config: since tg apps update turbogears.config at import time with, for example, tool.staticdirs (the widgets) I wanted the push/pop'ing that paste.config.DispatchingConfig has so the app factory can: 1) push the app's config dict, 2) import the RootController (lot's of config updates at import time going on..), 3) pop the config dict  4) goto 1 until all apps are initialize
[10:03] <albertov> d. Is there anyway to do something similar with just cherrypy? or maybe another way to deal with the problem?
[10:04] <albertov> chrismiles: yes, I think so...
[10:05] <albertov> fu_man_chu: the ultimate solution would be to avoid all this config stuff going on at import time but there should be a way to support 1.0 apps....
[10:05] <chrismiles> albertov: ok thanks.  I think I was getting confused about how much the cherrypy package should be abstracted away from TG.
[10:07] <albertov> chrismiles: good point.... maybe it would be a good idea to alias the cp equivalents into turbogears.request and turbogears.response in a similar way we do with config?
[10:08] <mramm> If there's a long term advantage to the switch I'd support it.   But I don
[10:08] <mramm> But I don't see any particular advantages to abstracting away request and response
[10:08] <albertov> chrismiles: we're using cherrypy for almost everything except the server initialization and some of the engine's functionallity (signal handling, process reloading and the deadlock timer). These are now handled by paster
[10:08] <mramm> and it's easy if people know where these things are comming from, and can look at the CP docs to see how they work.
[10:09] <albertov> mramm: good point. Then lets better avoid extra indirection...
[10:09] <chrismiles> yep, fair points.
[10:13] <fu_man_chu> from CP's point of view, as long as cherrypy.config and each app.config have the desired values at request.dispatch time, the rest doesn't matter--you can do whatever contortions you like ;)
[10:14] <mramm> Yea.
[10:18] <fu_man_chu> if I were doing it, I'd try to have turbogears.config pass everything to app.config except known global namespaces (like server.* and engine.*), and I'd even emit a DeprecationWarning for those if they're not in a [global] section
[10:19] <albertov> fu_man_chu: I think that point is already address (providing sane values at cherrypy.request.config *for* cherrypy) since the config is merged into the application just before handling it to the server. I'm more worried with accesses to config from user's code during a request since turbogears.config will give them the config that was passed in the "/" key when it was merged, not the folding that set_conf does into cp.req.config...)
[10:20] <nbm> hrm, I'm setting cherrypy.request.identity in a middleware, and I can't access it in the actual app
[10:20] <fu_man_chu> if you want to support 1.0 apps, you should be able to construct a singleton DefaultApp which turbogears.config assumes
[10:21] *** gasofred_ (n=chatzill@61-224-78-157.dynamic.hinet.net) joined
[10:21] <mramm> we could tell people to grab the config off of the request...  and for backwards compatability do the wht robert just suggested (only when started from start-myap.py not from tg-admin serve...)
[10:22] <albertov> nbm: that's normal, cherrypy.request does  not exist above the TG app... you should either stack that middlware below the TG app or pass it in environ
[10:22] <nbm> Phew.
[10:22] <nbm> I thought I was going mad.
[10:22] <fu_man_chu> heh
[10:23] <fu_man_chu> mramm, I think alberto is talking about code which needs config values outside of an actual request
[10:23] <nbm> Do we keep the environ around accessible from a request?
[10:24] <albertov> nbm: cp.request.wsgi_environ
[10:24] <nbm> Ta.
[10:25] <mramm> hmm, I thought he was looking for access to config durring a request...
[10:25] <fu_man_chu> yeah, I'm confused now :)
[10:26] <fu_man_chu> CP 3 is designed as Mark suggested: if you need config entries at request time, always get them from request.config
[10:26] <albertov> fu_man_chu, mramm: I'm worried about the discrepancy between accesses to tg.config anf cp.req.config during a request...
[10:26] <mramm> Yea
[10:26] <mramm> I think we should issue deprication warnings for tg.config
[10:26] <fu_man_chu> def tg.config.get(key): if in_request: return request.config[key]
[10:27] <mramm> and do what robert just suggested. ;)
[10:27] <albertov> ... and with a way to support 1.0 apps which access config outside a request so they don't contaminate each other.... otoh, maybe we shouldn't even support multiple 1.0 apps per process...
[10:27] <fu_man_chu> I don't see how you *could* support multiple 1.0 apps per process
[10:28] <mramm> Yea, if you want multiple 1.0 apps, you have to move to tg-admin serve and use the new config system.
[10:28] <mramm> At least that's what seems reasonable to me.
[10:29] <albertov> fu_man_chu: i was thinking by proxying those globals to objects bound to each app having some middleware setting up the context before each request (a la StackedObjectProxy)
[10:30] <fu_man_chu> why do all that when you already have request.app sitting there on each request?
[10:30] <fu_man_chu> request.app is the context
[10:31] *** gasofred quit (Read error: 110 (Connection timed out))
[10:31] <albertov> fu_man_chu: hmmm, interesting... wasn't aware of that....
[10:32] <gasofred_> the process is "tg-admin serve -> paste entry point -> call WSGIApp -> load configs -> running", right?
[10:32] <fu_man_chu> user code can, if it needs to, access request.app.config[section][key] if it needs to be aware of the whole app config
[10:32] <fu_man_chu> including ['/'][key]
[10:32] <fu_man_chu> which is where most app-wide config should go
[10:33] <albertov> so, the CP way of doing it would be: bind every "former" global to app and, for backwards compat, put a proxy where that service used to be? (eg: turbogears.scheduler -> cp.req.app.scheduler)
[10:33] <fu_man_chu> yup
[10:33] <albertov> gasofred: more or less: s/call WSGIApp/initialize WSGIApp/
[10:34] <fu_man_chu> and think about what to do if a user calls e.g. turbogears.scheduler outside of a request
[10:34] <fu_man_chu> that's case by case
[10:35] <albertov> fu_man_chu: hmmm, now I need to digest all this... (hope the irc logger is up and running... ;)
[10:35] <fu_man_chu> it isn't :(
[10:36] <albertov> really?
[10:36] <fu_man_chu> splee must have gone on vacation again >;)
[10:37] <albertov> :S and I can't find x-chat-aqua's "save chat"