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.
