What is the appropriate way to reference other "typed" variables in a config yaml? #595
-
I am attempting to read in a config file that references other values, some of which are typed with yaml tags such as Example codeThis is a minimum reproducible example code:
And here is the
So what I want is two python date objects from these two variables, but I can not manage to make that happen. With this first example,
If I change my test.yaml to include the
My questions
Thanks, and let me know if you need more info. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
@mkavulich Thanks for bringing this use case to our attention. It seems like we have an ordering problem here with when pyyaml interacts with the tag and when the Jinja template is filled in. We have a couple of other tags that we can use to help navigate this issue, like |
Beta Was this translation helpful? Give feedback.
-
I have replicated the example you provided and locally modified Here's the behavior I see with my local mod. Let me know if this is what you think might work. My
I use the CLI to replicate what you've shown in the API above:
It also works when I leave the
We do the same sort of thing when we reference other integers or float values using Jinja expressions. Check out this example where
We must use the
And without the
If this behavior makes sense to close this gap, I'll open a PR for it. |
Beta Was this translation helpful? Give feedback.
-
This new functionality has been proposed in PR #597 and will be available in our next minor release. |
Beta Was this translation helpful? Give feedback.
I have replicated the example you provided and locally modified
uwtools
to accept a!datetime
tag that will convert a Jinja expression to a datetime object after it's dereferenced. During that process, I also tested a theory that pyyaml understands an entry that looks like a date without the!!timestamp
tag, and found that it's unnecessary when you don't include quotes. This might make things a little less frustrating when the requirement to use a tag for the Jinja-templated version comes into play.Here's the behavior I see with my local mod. Let me know if this is what you think might work. My
test.yaml
contains: