This should be easy to do. I would take a patch to do it or I may be able to add it myself in two weeks.
Massimo On Jun 5, 12:04 am, Iceberg <iceb...@21cn.com> wrote: > 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 onhttp://localhost:8000/admin/default/sitefor 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 onhttp://localhost:8000/admin/default/sitefor > 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.
