A couple days ago, I came to the realization that including a config.py in quickstarted projects would be a good thing. Some settings are not dependent on the location of the app (dev vs. production)... they are intrisic to the app itself. Things like the template engine used or the encoding. So, I was thinknig it would make sense to move those out of the two INI-style files and into a py file that travels along with the egg for an app. Then, the .cfg files can be pared down to the real things that would vary between dev and production.
(Any settings that you'd need to compute dynamically could be done in config.py as well.) Kevin On 1/3/06, markc <[EMAIL PROTECTED]> wrote: > > I'm new to TG and python, so I'm only guessing, but this issue is going > to bite me too as I try to implement multihosting TG apps as simply as > possible. Unfortunately, having static (non-python) config ini files is > a problem. One potential long term option is to allow an extra > dynamically allocated dburi value that is dynamically worked out. In > the case of a file-system path for SQLite, a "path=dirname(__file__)" > at the top of the *-start.py file at the base of each project would > help determine any relative paths to the base of the current project > for the rest of the system which may be useful for a number of reasons. > This could be used for > sqlobject.dburi="sqlite:///full/path/to/sqlite.db" so that, for > instance, a sqlobject.dburi="this_sqlite:///relative/path/to/sqlite.db" > could then be expanded inside the core TG turbogears/database.py [in > set_db_uri() ?] such that the global "path" variable is interpolated > into the sqlobject.dburi value before being passed on to whatever code > actually uses it. In my case, a similar "host" var, which is set to the > equiv of PHPs $_SERVER['HTTP_HOST'], would provide all the dynamic > database name transforms that I would need... as well as a default site > name, until the site admin logged into the interface to update a > database entry for the sitename and logo image etc. Again, a default > sitewide logo could use the "path" variable + logo.jpg until a dynamic > database record was updated. I'm just pointing out where that global > "path" variable could be used to solve two needs. > > -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
