Regression: Unhelpful error message on missing variables

Summary

If a .bst file fails to specify a required variable, we receive a very unhelpful error message.

This has been reported before in #253 (closed) and was supposedly fixed by !449 (merged), however, I am seeing this behaviour on current master.

Steps to reproduce

I commented out the url of the tarball for the source of the hello.bst element in our autotools example

 $ cat elements/hello.bst 
kind: autotools
description: |

  Hello world example from automake

variables:

  # The hello world example lives in the doc/amhello folder.
  #
  # Set the %{command-subdir} variable to that location
  # and just have the autotools element run its commands there.
  #
  command-subdir: doc/amhello

sources:
- kind: tar
  # url: gnu:automake-1.16.tar.gz
  ref: 80da43bb5665596ee389e6d8b64b4f122ea4b92a685b1dbd813cd1f0e0c2d83f

depends:
- base.bst

 $ bst show hello.bst 
[--:--:--][        ][    main:core activity                 ] START   Loading elements
[00:00:00][        ][    main:core activity                 ] SUCCESS Loading elements
[--:--:--][        ][    main:core activity                 ] START   Resolving elements
[00:00:00][        ][    main:core activity                 ] FAILURE Resolving elements

autotools.yaml [synthetic node]: Dictionary did not contain expected key 'url'

What is the expected correct behavior?

We should at the very least get the filename.

---

added Bug Regression labels

changed the description

autotools.yaml [synthetic node]: Dictionary did not contain expected key 'url'

I think there are multiple problems here... Why would this say "[synthetic node]" ?

Clearly this provenance is coming from the plugin's autotools.yaml so how is this a synthetic node ?

Also, the expected location does exist in this case in the hello.bst above, so in this specific case, the provenance should be the dictionary of the Source declaration in the sources: list, and should also have it's line/column information.

Note that I think this is subtly different I think than the case we were discussing on IRC, take for instance a project.conf base level configuration:

• If the variable foo is not declared with any default value in data/projectconfig.yaml
• If the project.conf also does not provide the foo variable
• If the Project loads the foo variable and expects it to be provided

In the above case, there is no way that the code can provide context about where the variable foo is expected to be provided, and we bail out to an error that it was not provided in data/projectconfig.yaml, which of course makes no sense.

marked this issue as related to #253 (closed)

marked this issue as related to #591 (closed)

Note that #591 (closed) is more related to the issue that we cannot specify where we expect a value to be provided, when it is not provided at all and has no default.

I believe this is related to how the provenance of dictionaries (MappingNodes) is handled during composition.

I have what I believe to be a fairly simple fix which I'm trying out, but I need to organise a test for it.

mentioned in commit 0aca8364

mentioned in merge request !1551 (merged)

closed via merge request !1551 (merged)

mentioned in commit c627b220

mentioned in commit a5226c4b

mentioned in commit 055e2ac1