IMHO, flask and my lightweight proposal try to solve same problem.
Both can load configuration for sure. My proposal's loading ability
relies only on python's built-in import (via web2py's model
mechanism), therefore no need to introducing extra module. Isn't it
clean?

The basic challenge is how to separate and manage local setting from
default setting, and how to prevent the local setting being
distributed via app.w2p or Mercurial. Flask uses environment variable
YOURAPPLICATION_SETTINGS=/path/to/settings.cfg, to specify a local
setting. I like that too, but it can not be done via pure web2py admin
interface, so administrator need to ssh into their production machine
and make adjustments, and perhaps a kill-and-restart is needed. On the
contrary, in my proposal, although I did not emphasis this in earlier
post, administrator only need to visit standard web2py admin interface
and setup a new 0_local_setting.py. No ssh nor restart is needed,
again I rely on web2py's native behavior. Isn't it lightweight?

Of course, I don't like the
0_local_config_pls_dont_pack_dont_commit.py naming convention neither,
but I just did not come up with another descriptive name. The point
here, is we need a config file which can be used by a web2py app, but
not packed with the app.

Well, if we really just don't like the long and clumsy name
convention, then we can do it in a decent way:
1. introduce a applications/myapp/local_config directory, local
settings go into there.
2. adjust web2py to NOT pack, and NOT commit local_config directory
3. but we need more work for web2py's admin UI, to support add/edit/
view/delete setting file.

We can choose.


On Jun4, 3:26am, 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 = '....@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.

Reply via email to