Let me clarify and then summarize. First, .hgignore is one thing, "packing" is another. Ok we can leave the .hgignore out of web2py level, let each developer controls it by themselves. But when talking about "packing", I mean the "pack" feature on http://localhost:8000/admin/default/site for each app. It is a web2py way to built app.w2p package, especially for non-open- source project. So far, there is no way to built a w2p without leaking your current copy's local config content, even when .hgignore already setup by developer.
So, perhaps we could, at least, agree on a new "pack without databases" feature on http://localhost:8000/admin/default/site for each app? (Then I can put my own local_config.ini inside there) Regards, iceberg On Jun5, 1:55am, Thadeus Burgess <thade...@thadeusb.com> wrote: > I agree with Massimo, the NOT packing facility could be handled by .hgignore. > > As for configuration, I have used 0_config.py in blogitizor so that I > can run two versions, my personal version and the one that is open > source, this way my database and email information doesn't get leaked > out into the internetz. > > I use the following, > > http://code.google.com/p/blogitizor/source/browse/src/models/A_config... > > And then rename it to A_config.py and it won't get committed since > src/models/A_config.py is placed in my .hgignore file. > > However this isn't a web2py mechanism just a personal one, I don't > like the idea of making web2py in charge of this because then I the > developer lose control and can't change the way it works without > forking web2py. > > -- > Thadeus > > > > On Fri, Jun 4, 2010 at 3:28 AM, Iceberg <iceb...@21cn.com> wrote: > > Aside from the config issue, a flag when packaging that does not > > package the database/ folder, would be the long missing piece. And > > when this flag is available, I think I can have my own databases/ > > my_config.py to solve the local config problem in my style. :-) > > > So +1 for the "flag when packaging that does not package the database/ > > folder". > > > On Jun4, 2:20pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > >> I normally use > > >> #in models/0.py > >> from gluon.storage import Storage > >> settings=Storage() > >> settings.development=True > >> settings.email_sender=...@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.
