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 <doug.war...@gmail.com> 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 <thade...@thadeusb.com> > 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 <iceb...@21cn.com> 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 = 'f...@bar.com' >>> 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 <mdipie...@cs.depaul.edu> 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 <doug.war...@gmail.com> 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. >>> >> >
