New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to force data types in YAML after jinja expansion #72
Comments
This assumes templating happens before or during the YAML processing, it happens well after, so the YAML type would error out as templates are always strings, by definition. Type management is then done either in Jinja2 via filters for your case it would look like this: cpus: "{{ (ansible_processor_cores / 2)|float }}" Sadly this can be 'lost' when templating again, so you always want to use it on 'consumption' and not on 'definition', we have a PR to jinja2 itself to be better about preserving type but that will take time. |
The PR to preserve type in Jinja2 is pallets/jinja#708 |
Well, the YAML tag (what @bcoca calls type) errors out when it is a built-in one (2 As an example, you can check out how Odoo implements this. |
The problem as @bcoca mentioned with your specific implementation proposal, is that YAML and jinja parsing happen at different times. So trying to use YAML tags, doesn't work as expected. What happens is that when YAML is parsed the The above in your example tries to turn the literal string The PR that @dagwieers mentions is the appropriate solution. |
Well, I said lazy type transform for some reason. But indeed, pallets/jinja#708 is the best bet. |
@yajo, closing this proposal as per above. The real place to implement this is in Jinja2 itself. |
Proposal: Allow to force data types in YAML after jinja expansion
Author: Jairo Llopis <@yajo>
Date: 2017-09-19
Motivation
Sometimes you cannot use all of ansible+jinja power if the module did not define the right data type.
Problems
What problems exist that this proposal will solve?
Solution proposal
As explained in ansible/ansible#15249 (comment), Ansible should allow and parse YAML application-specific local tags that force a type cast after the value has been jinja2-evaluated
YAML itself has already type casters such as
!!int
or!!float
(double!!
), but those happen before jinja2, and thus they produce an error.Basically one should be able to add
!str
,!int
or!float
(notice the single!
) to any variable, either with or without jinja2 expansion, and it should get correctly type-casted after processing the jinja2 filters.For instance, this should then be a valid workaround for ansible/ansible#30548:
Testing (optional)
A simple
debug
task would be enough to test it IMHO.Documentation (optional)
Of course, this should be documented.
The text was updated successfully, but these errors were encountered: