Conditional questions

[yajo]

I guess this issue depends on #90 and it would let us declare questions to be conditional:

using_smtp:
  type: bool
  default: no

smtp_host:
  type: str
  when: '[[ using_smtp ]]'

[pawamoy]

If the conditions are only based on boolean values, do we really need #90, i.e. templating? The when is a special key, its value could simply be the name of the boolean field to check.

Besides, when rendering [[ using_smtp ]], you'd get a string (rendering a template always gives a string), so we would need to cast "True" or "False" back to a boolean? What if the user writes something a bit more complex and we cannot cast it back?

So instead, I suggest

using_smtp:
  type: bool
  default: no

smtp_host:
  type: str
  when: using_smtp

It would be easier to implement as a first step, and still allow to enhance the behavior later with templating if needed. WDYT 🙂 ?

[yajo]

Well, that's half true.

Recent Jinja versions have the NativeEnvironment, which returns the native object type if possible: https://jinja.palletsprojects.com/en/2.11.x/nativetypes/

If we do this initial step and leave the fully templated when for a future improvement, when it comes it wouldn't be easy to be made backwards-compatible with this one, because with when: using_smtp you assume "using_smtp" is the name of a bool answer, but with that future system it would be just a "using_smtp" string, and the bool answer would be detected with when: "[[ using_smtp ]]".

Since #90 is in the roadmap too, I still think we should still implement #90 before. After it's done, this issue would be simpler and we'd still have full templating possibilities with not much more effort.

[pawamoy]

Didn't know about this NativeEnvironment, nice!

Then this totally makes sense as it will be possible to have conditionals like "[[ using_smtp or using_imap ]]", which would be much more powerful.