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.
>>
>
