Skip to content
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

Feature: Use Jinja's new NativeEnvironment to get native types instead of strings! #3828

Open
cognifloyd opened this issue Nov 4, 2017 · 7 comments
Labels

Comments

@cognifloyd
Copy link
Member

cognifloyd commented Nov 4, 2017

It's really hard to deal with magically converting from Jinja strings back into native python types. Let's just skip the conversion and use native python types.

How you ask? Jinja has merged a pretty cool PR: pallets/jinja#708
Here's a quote from the new doc:

The default jinja2.Environment renders templates to strings. With NativeEnvironment, rendering a template produces a native Python type.

This consists of three basic parts: NativeCodeGenerator, NativeTemplate, and NativeEnvironment. Check out the code. This will land in Jinja 2.10.

This comes from an ansible PR by @jctanner: ansible/ansible#23943

I suspect that using NativeEnvironment would resolve (or make a big dent in) these:

@arm4b arm4b added the feature label Nov 4, 2017
@Kami
Copy link
Member

Kami commented Nov 6, 2017

Thanks for letting us know about this.

It seems like a great overall feature which would help in a lot of scenarios. Having said that, the change will probably be quite big and we also need to research it to make sure it's actually a good for our use case (need to make sure it works across Python versions and not like pickle, need to research safety of this feature, etc).

Also, #2976 is not related to Jinja, but to the way we store and serialize values in the datastore.

@cognifloyd
Copy link
Member Author

@nmaludy
Copy link
Member

nmaludy commented Nov 9, 2017

#3820 might also be related and/or fixed using this feature

@cognifloyd
Copy link
Member Author

And here's how simple it is for Ansible to switch over to using NativeEnvironment:
ansible/ansible#32738
And here is his test playbook for using it:
https://gist.github.com/jctanner/32df50fe270096afc7fe2582e2d21b8c

@cognifloyd
Copy link
Member Author

@Mierdin said this in #3909

This kicked off a long discussion internally, and we've decided to go for a more robust, exhaustive method of dealing with more complicated data types, likely to be implemented in the 2.6 release timeframe, perhaps 2.7.

That effort could be related to (or perhaps made easier with) this feature.

@cognifloyd
Copy link
Member Author

cognifloyd commented Oct 10, 2018

This is a major-ish change - Maybe this can go in 3.0? Or make its way onto the roadmap? (Please)

@smemsh
Copy link

smemsh commented Dec 13, 2019

think this is what's implemented and merged in #32738, looks like it was relased in ansible v2.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants