On May 21, 2007, at 10:53 PM, Ian Charnas wrote:
> > So are we still on for a TurboGears sprint this upcoming saturday? > How do we do this? Do we all jump on IRC at a certain time and decide > what to do? It'll be probably be good to open up a page in the docs.tg.org wiki to make some planning... I'll be in to work on a new test infrastructure to eventually port all failing controller tests to put TG back in the "green" zone. The other big task needing work is poring the config module to CP3's new config system . Some coordination between my work and the "config team" is needed since a pre-requisite to my part is to have a TG app nicely wrapped in a WSGI app (possibly with a paste.app_factory entry- point implemented) since I'm planning to use paste fixture for the testing. Some notes + brainstorming: CP3 uses the Application object to create the mentioned WSGI app which receives the app's config as a constructor's parameter so we'll have to agree on how we create initialize this object. Maybe something like this: - add a new wsgiapp.py module inside quickstarted apps which implements the paste.app_factory entrypoint to return a TG/CP3 app. This module uses some helper functions inside TG's startup.py (or even a TGWSGIApp Application subclass) to initialize and stack TG's specific middleware (none ATM, expect EvalException, but we need to leave room for future growth). - This entrypoint could be called by PasteScript's paster passing a paste.deploy config file which would override config parameters defined in well knownt app.cfg et al. tg-admin should grow a new "serve" commad (which delegates to paster serve) which loads a TG app with no paste.deploy config and mounts it at /. This new "serve " commands deprecates good 'ol start-myapp.py (which can be left as a backwards compatibility artifact which simply delegates to tg-admin serve). A quick mental topological sort leaves tasks in this way: 1) wrap TG apps with CP3's Application object 1.5) (at this point I can start migrating the testing framework) 2) this Application object receives an app config dict so... adapt current config.py so it can load TG' config and pass it to the Application constructor. The "config" team could work on a rewrite of the config module so it produces a properly formatted config dict to feed to Appliaction) 3) implement the paste.app_factory entry point which can receive a *possible* paste.deploy config or a dummy one that points to app.cfg and returns this WSGI app object. The possible paste.deploy config should override values in app.cfg if present. 4) implement the tg-admin "serve" command 5) glue all this together so "tg-admin serve my.config" launches a TG app and start-myapp delegates to this Sorry for my poor communication of this ideas.... I'm speaking from memory and it has been months since other work has displaced this task from the foreground of my badly multi-tasking brain ;) Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
