I normally use
#in models/0.py
from gluon.storage import Storage
settings=Storage()
settings.development=True
settings.email_sender='m...@example.com'
...
Anyway, this does not address Iceberg's problem of packing some config
files and not others. I am not convinced this scenario should be
handled at the web2py level. This is better handled using .hgignore
and mercurial or other version control system.
I am thinking anyway, to allow a flag when packaging that does not
package the database/ folder. So in principle one could create
function that updates parameters from a DAL('sqlite://settings.db')
On Jun 4, 1:10 am, Iceberg <iceb...@21cn.com> wrote:
> 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.
