i think part of the problem is the modulename argument being passed to update_config()... when this is done, config_obj() ends up making a ConfigObj for every cfg file in the module dir, with "staging" winning since it's last alphabetically.
if i don't pass in the modulename, the startup script crashes when calling configure_loggers(), since config_obj() ends up returning an empty dict. On Feb 1, 11:04 am, "jemminger" <[EMAIL PROTECTED]> wrote: > are you sure? it looks to me that it's looking for your cfg file > argument, if not given then falling back to setup.py if it exists, > failing that it loads prod.cfg > > i've even added print statements to it like such: > > # first look on the command line for a desired config file, > # if it's not on the command line, then > # look for setup.py in this directory. If it's not there, this script > is > # probably installed > if len(sys.argv) > 1: > print "arg 1: %s" % sys.argv[1] > turbogears.update_config(configfile=sys.argv[1], > modulename="claimsqa.config") > elif exists(join(dirname(__file__), "setup.py")): > print "found setup.py" > turbogears.update_config(configfile="dev.cfg", > modulename="claimsqa.config") > else: > print "assuming prod.cfg" > turbogears.update_config(configfile="prod.cfg", > modulename="claimsqa.config") > > ... and i've added a print statement to turbogears.update_configto > show what was passed in: > defupdate_config(configfile = None, modulename = None): > print "update_config(%s, %s)" % (configfile, modulename) > > and the output is such: > C:\home\jeffe\python\tg\claimsqa>start-claimsqa.py dev.cfg > arg 1: dev.cfgupdate_config(dev.cfg, claimsqa.config) > 2007-02-01 10:46:52,772 cherrypy.msg INFO CONFIG: Server parameters: > 2007-02-01 10:46:52,802 cherrypy.msg INFO CONFIG: > server.environment: staging > > as you can see, i pass in dev.cfg, it says it's callingupdate_config > with dev.cfg, yet cherrypy still starts in "staging" mode > > so either i'm crazy or it isn't working right?!? > > On Feb 1, 1:11 am, "Jorge Vargas" <[EMAIL PROTECTED]> wrote: > > > On 1/31/07, jemminger <[EMAIL PROTECTED]> wrote: > > > > using TG 1.0 on windows > > > > in projectname/projectname/config, i have three environment config > > > files: > > > dev.cfg > > > staging.cfg > > > prod.cfg > > > > however, when i start the server e.g. "start-projectname.py dev.cfg", > > > it doesn't matter what i specify as the config file, it always chooses > > > the next "higher" environment up from dev... i.e. if all three > > > environment cfg files are present, no matter what i specify as the > > > config file it will always start in staging mode. if i move the > > > staging file away, it will start in production mode. the only way to > > > have it start in dev mode is to have dev.cfg be the only environment > > > file present in the config dir. > > > take a look of what start_project does, it's internal logic is what's making > > you fail. It is coded based on the assumption that you only have > > dev/prod.cfg but you can edit it to work as you wish. as long as > >update_configis call TG is happy > > > if it matters, this project was created on TG 0.9.4 or so, though i > > > > did try to replace the relevant bits in the start-projectname.py file > > > with code created by TG1.0 quickstart, and got the same results. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en -~----------~----~----~----~------~----~------~--~---
