It's a little odd, but it makes sense once you understand why it was done that way.
For the benefit of future searchers: The app.cfg file contains all the stuff that won't change regardless of environment, and the dev.cfg/prod.cfg files have config options that are, as mentioned, environment-specific. Kevin Horn On 2/8/07, jemminger <[EMAIL PROTECTED]> wrote: > > > [solved] > > duh - the reason it wasn't working is because i had my environment- > specific config files in /project/project/config/, instead of just / > project/. rather confusing though, since app.cfg does go in /project/ > project/config/ > > > On Feb 1, 11:31 am, "jemminger" <[EMAIL PROTECTED]> wrote: > > 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.pyfile > > > > > 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 -~----------~----~----~----~------~----~------~--~---
