1

Coming from a Django background, I'm accustomed to the framework providing a configuration mechanism which is suitable (and intended) for app-layer configuration rather than framework configuration only.

The TurboGears 2.x template includes a <app_module>.config.app_cfg module, which can be overridden by deployment ini files; however, this is explicitly documented as being for "TG2-specific" settings, and I don't see any kind of naming convention or namespace mechanism documented which would prevent a configuration entry I come up with for my app from colliding with new settings added to other framework components in the future.

Does TurboGears 2.x provide, or does the set of accepted best practices for TG2 developers (Paste, etc) include, any mechanism for managing configuration for applications built on TG2, not specific to TG2 itself? If reusing the TG2 configuration mechanism is conventional, is there any accepted practice for configuration namespace management?

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441

1 Answers1

3

The config in TurboGears2 supports complex structures, for example you can declare the options for your application inside myapp.option1 myapp.option2 and so on. They will be accessible inside your application both as tg.config['myapp.option1'] and tg.config.myapp.option1.

This way you will avoid collisions.

Options can be set both in your development.iniand config.app_cfg.

For example, if you put inside your app_cfg

base_config['myapp.option1'] = 'FOOBAR'

the FOOBAR string will be accessible from tg.config.myapp.option1

Pay attention that base_config object overwrites options loaded from the .ini configuration file.

amol
  • 1,771
  • 1
  • 11
  • 15