-
Notifications
You must be signed in to change notification settings - Fork 24k
yaml filters now use 'ansible yaml' #81727
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
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm kinda torn about this overall...
In the process of determining which of our serialization formats would support round-tripping datatags, we leaned pretty heavily on the fact that from_yaml
didn't support any custom tags today as justification for not defining a YAML tag scheme for datatags (which will be very difficult to do properly, given the limitations of YAML's tagging/type system). Even with this change, to_yaml
still only preserves vault
, not unsafe
.
JSON is really our only "full fidelity round-trip capable" data interchange format today, and I'm thinking we should try to keep it that way. There are so many other gotchas around using Jinja to rewrite Ansible content that it might be good to just continue to let it fail early if someone's trying, rather than letting some stuff through. We'd also continue to fail on any doc that had other undefined tags, and since PyYAML doesn't provide anything out of the box to preserve that stuff, I think it's a lot easier to explain that those filters just don't support tagged data at all rather than defining a special subset that we'd likely face pressure to increase over time.
Doing multi-stream YAML support this way is also problematic, since it's now impossible to tell the difference between a doc with a root list and a list of docs. If we end up using multi-stream and need to support that with the filters, it probably needs to be a custom wrapper type that actually provides the context for each document.
The multidoc support in the filters is preexisting, I just adapted it to be able to use Ansible's YAML as users were hitting an issue when exporting/generating the YAML and not being able to reimport/handle via the filters. If we don't want to support having the filters understand/handle 'ansible YAML' then i can just turn this into a documentation PR. |
aa0bb98
to
22d8712
Compare
22d8712
to
b35d74a
Compare
b35d74a
to
d4253ad
Compare
The test
The test
The test
The test
The test
|
Now they can process things like
!unsafe
and!vault
ISSUE TYPE