For context, please see http://flask.pocoo.org/docs/config/ http://flask.pocoo.org/docs/api/#configuration
-- Thadeus On Thu, Jun 3, 2010 at 4:55 PM, Thadeus Burgess <[email protected]> wrote: > Exactly, We can copy flask and add the same configuration module which > implements everything and more of what you just described. > > -- > Thadeus > > > > > > On Thu, Jun 3, 2010 at 4:33 PM, Doug Warren <[email protected]> wrote: >> What I was thinking was something we use in the gaming world, called a >> console variable, you can specify their values in code, in a config >> file, through an in app interface, or through the command line. >> >> In web2py terms, I was thinking to make a global singleton that when >> first instantiated would scan sys.argv for things that looked like >> command arguments in the form of +Key Value or +Key=Value and then >> parse that to a global vs appliation level dict IE: >> +welcome.banner="Hello" vs +admin.banner "Hola" vs banner="hi" when an >> application queries the system, it would exec request.env.web2py_path >> + appliation which would look like: >> >> convars = ConVars() >> convars.database_string = "sqlite://file.sql" >> convars.debug = 1 >> convars.arbitrarysettinghere = 2 >> >> further dragging in new variables and overriding those that are on the >> command line. (This last distinction is open to debate as it could be >> considered easier to change a file than to change the command line.) >> There would also be a global level file to be read that can just >> define all known variables and their defaults. Finally a database >> table could be defined and a controller set that would represent the >> final most dynamic version of the config that can be updated in real >> time. >> >> A db or controller could then invoke it like >> convars = ConVars(request) >> if convars.debug: >> # Handle debug case >> >> >> On Thu, Jun 3, 2010 at 12:26 PM, Thadeus Burgess <[email protected]> >> wrote: >>> Or... we can copy flask and integrate a configuration module.. >>> >>> God I pray we never use something like >>> `0_local_config_pls_dont_pack_dont_commit.py` INTO web2py. web2py and >>> its naming conventions >.< >>> >>> -- >>> Thadeus >>> >>> >>> >>> >>> >>> On Thu, Jun 3, 2010 at 10:22 AM, Iceberg <[email protected]> wrote: >>>> I think Doug's puzzle deserves a more general solution. The >>>> requirement and challenge is: >>>> R1. The app's central source code should contain default setting. >>>> R2. The app's multiple deployment instances should be allowed to >>>> contain its local setting. >>>> R3. And after the next "hg update", the default setting in (R1) should >>>> not override the local setting in (R2). >>>> >>>> >>>> My solution contains two steps: >>>> Step1: Use myapp/models/0_config.py to store default setting, such as: >>>> MY_HOST = 'http://localhost' >>>> MY_EMAIL = '[email protected]' >>>> MY_PASSWORD = 'blah' >>>> MY_DB = 'sqlite://storage.sqlite' >>>> >>>> Step2: Use myapp/models/0_local_config_pls_dont_pack_dont_commit.py to >>>> store instance-wide local setting, such as: >>>> MY_HOST = 'http://myaccount.my_vps_provider.com' >>>> MY_EMAIL = 'my_real_acco...@for_example_hotmail.com' >>>> MY_PASSWORD = 'i_will_never_share_it' >>>> MY_DB = 'mysql://10.1.1.1.....' >>>> >>>> >>>> To reach this goal, two things need to be adjusted in web2py source >>>> code: >>>> >>>> Thing1: add 0_local_config_pls_dont_pack_dont_commit.py into / >>>> web2py/.hgignore >>>> >>>> Thing2: adjust the admin's pack code, to NOT pack the new >>>> 0_local_config_pls_dont_pack_dont_commit.py >>>> >>>> On Jun3, 10:23pm, mdipierro <[email protected]> wrote: >>>>> they can see request.env.host_name and you can use hostnames like <bla >>>>> bla bla>.yourdomain.com >>>>> >>>>> you can symlink different apps to the same one so you have one but it >>>>> will see different request.application depending on the request >>>>> >>>>> On Jun 3, 8:50 am, Doug Warren <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> > Is there a preferred way to handle multiple instances of the same >>>>> > application installed on the same machine? Say for instance is >>>>> > there's 3 dev environments and 2 staging environments on one server >>>>> > pointing at different databases? Is there a preferred way of getting >>>>> > the configuration to each unique app? IE: Can a view/db/controller >>>>> > see a parameter placed in either options_std or parameters_PORTNO? I >>>>> > guess what I'm really after is a way to specify at a minimum the >>>>> > database that an application can point at but have it contained >>>>> > outside the application itself. >>>>> >>>>> > IE: >>>>> > foo.w2p is uploaded >>>>> > foo.w2p is installed as foo >>>>> > foo.w2p is installed as foo-dev >>>>> > foo.w2p is installed as foo-dev2 >>>>> > foo.w2p is installed as foo-stag >>>>> >>>>> > Without having to edit db.py in each of those environments I'd like to >>>>> > have a way of saying foo-stag should use this connect string, and have >>>>> > it survive the next time I upload a new foo.w2p and overwrite the one >>>>> > that's there. >>>> >>> >> >
