So what would be the strategy for having config settings for dev and
production?
Would there be some way to branch on is_local?
On Sunday, July 19, 2015 at 12:06:42 PM UTC-7, Alex wrote:
>
> it's a clear separation of code and configuration. When you deploy the
> application on a server you us
or an env variable.
On Friday, April 15, 2016 at 7:47:19 AM UTC+2, pbreit wrote:
>
> So what would be the strategy for having config settings for dev and
> production?
>
> Would there be some way to branch on is_local?
>
>
> On Sunday, July 19, 2015 at 12:06:42 PM UTC-7, Alex wrote:
>>
>> it's a
But is there a good or proscribed way to use AppConfig for Dev and Prod
settings?
If I do JSON can I do something like:
{
"dev": {
"db": sqlite
}
"live": {
"db": postgres
}
}
and then something like:
if is_local:
myconf = AppConfig(reload=True)['dev']
--
Resources:
- http:/
Even better would be some sort of inheritance so you only end up overriding
a handful of settings in production.
Was this intended for that or should I be looking elsewhere?
On Friday, April 15, 2016 at 8:25:54 AM UTC-7, pbreit wrote:
>
> But is there a good or proscribed way to use AppConfig fo
appconfig is the tool, you are the brain. Everyone has its own
preferences.
Personally I use a post-deployment step to fiddle with settings, as
DEPLOYment is not DEVELOPment.
You can use a SINGLE env variable to switch configs
prod_conf = os.environ('isthisprod')
if prod_conf:
myconf
On Friday, April 15, 2016 at 9:52:22 AM UTC-7, Niphlod wrote:
>
> appconfig is the tool, you are the brain. Everyone has its own
> preferences.
> Personally I use a post-deployment step to fiddle with settings, as
> DEPLOYment is not DEVELOPment.
>
> You can use a SINGLE env variable to
On Friday, April 15, 2016 at 10:40:03 AM UTC-7, Dave S wrote:
>
>
>
> On Friday, April 15, 2016 at 9:52:22 AM UTC-7, Niphlod wrote:
>>
>> appconfig is the tool, you are the brain. Everyone has its own
>> preferences.
>> Personally I use a post-deployment step to fiddle with settings, as
>>
Here's what I ended up with:
```
import os
config_path = os.path.join(request.folder, 'private')
if request.is_local:
myconf = AppConfig('%s/appconfig-dev.ini' % config_path, reload=True)
else:
myconf = AppConfig('%s/appconfig.ini' % config_path, reload=False)
```
--
Resources:
- http://
Two more questions:
It would seem "take" is preferred since there's some sort of performance
caching? Is there any reason to do "get"?
Can appconfig params be strings with interpolation?
Ex:
[url]
local_server = http://127.0.0.1/%s/details
And then in code:
requests.get(myconf.take('local_ser
it's faster and reads config files automatically. and you don't need to
redefine a storage at every request.
On Friday, April 3, 2015 at 1:43:50 PM UTC+2, 黄祥 wrote:
>
> hi,
>
> i notice that the new 2.10.3 have an AppConfig what is the difference with
> Storage?
> At the earlier i usually use S
thank you simone for explanation, another question is about
*earlier 0.py*
settings.migrate = True
settings.actions_disabled = ['profile', 'register']
*current appconfig.ini*
migrate = 1
is the migrate change from True into 1, i know 1 is True and 0 is False?
is appconfig.ini is support list li
if you look at the source code, you'll see that it's just an ini parser by
default.
All that it does is speedup the "settings" part without users knowing
anything about python (think when you finish an app and you deploy it on a
system you may not have access to, or if you ship an app to your u
>
>
> Beware: since it's made for speed, once you take out the "reload" on the
> initialization, values will be stored indefinitely as they are fetched the
> first time.
>
agreed, already tested it. imho, i think is still not stable.
e.g.
private/appconfig.ini
[auth]
actions_disabled = ['prof
Once again: it's just an ini parser that works as a singleton when you
don't pass reload: it's not black magic.. but it's not made to hold
every bit of python syntax (if you want it, you don't need appconfig, just
use models and modules.)
You calling it "not stable" is just calling SafeConf
i understood now, thank you so much for detail explaination and reference
link, simone.
thanks and best regards,
stifan
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Repo
in 0.py by using Storage:
develop = False
develop = 0
develop = ''
all is work
in appconfig.ini
develop = False
develop = 0
develop = ''
setted as True !!!
We need use now it:
develop =
((
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/
sorry, what ?!?!?!
On Sunday, July 12, 2015 at 11:21:04 PM UTC+2, ermolaev...@gmail.com wrote:
>
> in 0.py by using Storage:
>
> develop = False
> develop = 0
> develop = ''
>
> all is work
>
> in appconfig.ini
> develop = False
> develop = 0
> develop = ''
> setted as True !!!
>
> We need use now
if I init some var in appconfig.ini:
my_var1 = False
and then use it in code:
if my_var1: -> will use as True
so I need use in appconfig.ini that code:
my_var1 =
понедельник, 13 июля 2015 г., 19:35:59 UTC+3 пользователь Niphlod написал:
>
> sorry, what ?!?!?!
>
> On Sunday, July 12, 2015 at
that's how ini parsers work: they parse the value as strings. you can force
a conversion of the type using a cast function passed to the take()
function. Get the inspiration from the scaffolding app, it's all there.
On Tuesday, July 14, 2015 at 6:41:29 PM UTC+2, ermolaev...@gmail.com wrote:
>
>
thanks for the AppConfig implementation! this is really useful and allows
easy configuration of db connections. Actually I posted a question about
this a few years ago - in the meantime I found a workaround but I'll change
it to AppConfig soon.
Is this already mentioned in the book somewhere? I
why it better than code in /models/0.py ?
response.db_cs = 'DB_CONN_STR'
or
DB_SC = 'DB_CONN_STR'
четверг, 16 июля 2015 г., 5:29:03 UTC+3 пользователь Alex написал:
>
> thanks for the AppConfig implementation! this is really useful and allows
> easy configuration of db connections. Act
it's a clear separation of code and configuration. When you deploy the
application on a server you usually have a different database connection
string (and maybe other different settings as well), usually even multiple
setups for dev, test and so on. Without a configuration file you'd have to
c
22 matches
Mail list logo
