apply_transformation() error when called with a 'ruamel.yaml.MappingNode'

[jcberquist]

I am trying out the latest version of YAML-Macros and given the following source:

  template-expression:
    !template_expression
    meta_content_scope: source.cfml.script

I see the following error:

Error in macro execution.
  in "<file>", line 317, column 5

Traceback (most recent call last):
  File "...\Sublime Text 3\Packages\YAMLMacros\src\engine.py", line 70, in multi_constructor
    return apply_transformation(loader, node, macros[suffix])
  File "...\Sublime Text 3\Packages\YAMLMacros\src\engine.py", line 58, in apply_transformation
    args = loader.construct_mapping(node)
  File "..\Sublime Text 3\Packages\ruamel-yaml\st3\ruamel\yaml\constructor.py", line 1265, in construct_mapping
    self.check_mapping_key(node, key_node, maptyp, key, value)
  File "...\Sublime Text 3\Packages\ruamel-yaml\st3\ruamel\yaml\constructor.py", line 245, in check_mapping_key
    if key in mapping:
TypeError: argument of type 'NoneType' is not iterable

Looking at constructor.py I see several construct_mapping methods in the various classes. The construct_mapping method that is getting called in the trace above is the one in the RoundTripConstructor which seems to need a map passed in, and also doesn't return anything (meaning args will always be None after line 58).

I know a lot of work has gone into YAML-Macros recently, so is there something I need to change on my end?

[jcberquist]

In order to successfully build I replaced

args = loader.construct_mapping(node)

with

ret = ruamel.yaml.comments.CommentedMap()
loader.construct_mapping(node, ret)
args = dict(ret.items())

While that works (in the sense that a build completes), I have no idea whether it is a real solution.

[Thom1729]

This is a weird bug -- weird because that code path is actually working most of the time. I don't know why it would work in some cases but not others.

In any case, I've released v3.0.4 with basically the fix you suggested. That should be correct.

Ideally, version 3 should be perfectly backward-compatible, although one or two things are deprecated. Thanks (and apologies) for finding the bug!

[jcberquist]

Thanks for the quick fix!