How to handle dependent settings in Django + Dynaconf

[mjmare]

In my Django settings.py file I have some settings that depend on DEBUG. Eg:

DEBUG = True
:
CRISPY_FAIL_SILENTLY = not DEBUG

What is the recommended way of handling this with Dynaconf, when I move the DEBUG setting to a yaml file? Since Dynaconf is only initialised at the end of settings.py, after the (current) usage of DEBUG.

TIA

[mjmare]

No takers?

[pedro-psb]

Hello @mjmare, sorry for the delay.
I recommend using template substitutions:

# project/settings.py
CRISPY_FAIL_SILENTLY = "@bool @jinja {{ not this.debug }}"

# settings.yaml
default:
  debug: true

This works because jinja and format formatters will create a Lazy object that is evaluated upon access.
Let me know if this works for you, I'll be around this week.

[rochacbruno]

@pedro-psb I was thinking about adding a new converter like:

KEY="@expr not this.debug"

Any valid Jinja expression would be supported. (install jinja required)

and then we can use Jinja to evaluate the expression

from dynaconf.utils.parse_conf import jinja_env

result = jinja_env.compile_expression("1 + value")(value=2)

That could be added as a lazy value

def evaluate_expr(expr, **context):
    return jinja_env.compile_expression(expr)(**context)


converters["@expr"] = lambda value: Lazy(value, formatter=evaluate_expr)

[mjmare]

That looks like a practical solution.
What does the "this" refer to exactly? Would it handle the situation with multiple settings files?

[pedro-psb]

this refers to the current set of settings on the time of evaluation (internally, it is a special kind of dictionary). In another words, it refers to the resultant union and merge of multiple setting sources, so it should work in this scenario.

[mjmare]

Thx

[pedro-psb]

@rochacbruno I guess this would be appropriate. There is an issue related to this (math expressions), but it should be handy to have a general expression mechanism which is more obvious than using jinja directly. Also, I think that as an expression evaluator it should be able to infer the proper casting (int, float, bool) with some simple rules, like:

- if contains explicit boolean, keep boolean
- if convertible to int, use int
- if convertible to float, use float

[rochacbruno]

@pedro-psb JInja will return the value casted to valid Python, ex: "1 == 1" will return a boolean.