Sounds like a great idea, but i'm not sure it's that good to use two different config formats (py and ini).
On 1/3/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > > 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 > -- cheers elvelind grandin
