Open aqw opened 3 hours ago
This turns out to be a "bug" in the YAML spec, and ruamel is correctly following their insanity.
Words fail me.
I will fix our inventory repo to no longer use underscores with integers. And will add this to the list of fsck checks.
Closing.
Comment: I don't know whether this would have been protected against by treating all key names as strings. (#671). I think the key name would need to be quoted to begin with.
Comment: I don't know whether this would have been protected against by treating all key names as strings.
I do currently think, that is the right direction.
We convert keys to strings currently only within dot notation (and there we have to), and that is the actual problem here.
We get an integer key and then end up accessing a (wrongly) stringified version of it, which fails.
Instead, we need to stringify the keys we get when reading the YAML, and do so by utilizing ruamel's internal knowledge of how it's actually represented (roundtrip), so we get '3_5'
in this case rather than str(35)
.
Otherwise there likely will be a lot of corner cases where confusing errors happen.
In this case here, we get an error about a key, that the user didn't say to do anything with. This type of thing will remain troublesome, if we don't solve it properly.
But if it works as I currently think, there would be no need to restrict the YAML.
So - re-opening, since this needs addressing (and I think I know how).
This is easiest to explore in our inventory repo, but I will try to provide some context:
Some assets contain the following structure:
However, when I try to perform any form of write action on that asset, it results in an error:
Reading is a different story
The
connectors
key works, but something is weird/wrong with3_5
:When I edit the asset manually and change
3_5
to3-5
, everything is fine again:When I enable debugging, I get the following traceback:
This behavior is reproducible with
onyo new
and templates.