No support for !Sub and other AWS-like yaml extensions

[bedge]

I have no idea whether tehse are "standard" yaml or not, but it would be super useful if this supported the !XXX yaml extensions that AWS uses. eg:

  LambdaExecRolePolicies:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: !Sub '${OwnerNamespace}-${AssetNamespace}-execution-${FunctionName}'

This currently results in the following stack trace:

LambdaExecRolePolicies: Type: AWS::IAM::Policy Properties: PolicyName: !Sub '${OwnerNamespace}-${AssetNamespace}-execution-${FunctionName}' ❯ cat ig1xm-iam.yaml | shyaml get-value AWSTemplateFormatVersion Traceback (most recent call last): File "/usr/local/bin/shyaml", line 459, in sys.exit(main(sys.argv[1:])) File "/usr/local/bin/shyaml", line 397, in main contents = yaml.load(sys.stdin) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/init.py", line 72, in load return loader.get_single_data() File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 37, in get_single_data return self.construct_document(node) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 41, in construct_document data = self.construct_object(node) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 86, in construct_object data = constructor(self, node) File "/usr/local/bin/shyaml", line 119, in construct_omap return MyOrderedDict(cls.construct_pairs(node)) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 141, in construct_pairs value = self.construct_object(value_node, deep=deep) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 86, in construct_object data = constructor(self, node) File "/usr/local/bin/shyaml", line 119, in construct_omap return MyOrderedDict(cls.construct_pairs(node)) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 141, in construct_pairs value = self.construct_object(value_node, deep=deep) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 86, in construct_object data = constructor(self, node) File "/usr/local/bin/shyaml", line 119, in construct_omap return MyOrderedDict(cls.construct_pairs(node)) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 141, in construct_pairs value = self.construct_object(value_node, deep=deep) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 86, in construct_object data = constructor(self, node) File "/usr/local/bin/shyaml", line 119, in construct_omap return MyOrderedDict(cls.construct_pairs(node)) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 141, in construct_pairs value = self.construct_object(value_node, deep=deep) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 86, in construct_object data = constructor(self, node) File "/usr/local/Cellar/shyaml/0.5.2_1/libexec/lib/python3.7/site-packages/yaml/constructor.py", line 414, in construct_undefined node.start_mark) yaml.constructor.ConstructorError: could not determine a constructor for the tag '!Sub' in "", line 34, column 19

I realize this is a super-specific case, but from a user case POV, it's not uncommon.

[geerlingguy]

They're definitely not standard, and many different parsers have issues with them. What I've done for most of my CF stacks is to use the slightly more verbose, but completely valid alternative structure, e.g.:

 LambdaExecRolePolicies:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName:
        Fn::Sub: '${OwnerNamespace}-${AssetNamespace}-execution-${FunctionName}'

[bedge]

I can live with that for my own work, but being a usurper of the work of others, the downside is that the other exists in the wild and is not going away. Thanks for the alternative syntax hint.