Repository navigation
Line number quoted in parsing errors is fairly useless #51
Description
Activity
I think that is related to strictyaml not being able to properly process comments:
so in this example:
# Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the # "License"); you may not use this file except in compliance # with the License. You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, # software distributed under the License is distributed on an # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, either express or implied. See the License for the # specific language governing permissions and limitations # under the License. github: description: "Apache CloudStack Website" homepage: https://cloudstack.apache.org/the starting_line of the first yaml feature (github) is actually 1, though it is actually 18.
It's mainly because the YAML is parsed as separate chunks; the feature code is only passed the section of the YAML it is registered to handle.
The line number is correct as far as the validation of the part is concerned, but is not useful for the end user.
oh I was already too far ahead, you are correct that currently it does not work at all as you describe. However, when taking into account the
start_lineof the YAML instance, you will see that we cant fix it right now:except strictyaml.exceptions.YAMLValidationError as e: feature_start = feature_yaml.start_line e.problem_mark.line = feature_start + e.problem_mark.line # feature_start will not be the correct line in the source yaml file when comments are present raise ASFYAMLException( repository=self.repository, branch=self.branch, feature=feature_name, error_message=str(e) )Unfortunately the following line does not change the value:
e.problem_mark.line = feature_start + e.problem_mark.lineIt looks like the Exception object is somehow preventing updates to the problem_mark object.
Turns out that's because the object generates the problem_mark object from a YAMLChunk, which in turn generates the value.
I don't see a way to fix the line number, short of patching the code that generates the message string to add the offset.
A better solution might be to ensure the file syntax is checked as a whole.
The features could register their schemas with the main logic for it to check.That would require an overall schema.
My suggestion was to move to pydantic that would allow that quite easily.
@Humbedooh mentioned that he will look into it, and when I have some time I also want to experiment with it, but it will certainly require some changes so not a trivial change imho.Edit: actually using pydantic will not help with the line numbers as it will not load the yaml file itself, but rather process the dict that is the result of parsing it with a yaml parser. If a validation error occurs you usually get a descriptive error message where the error occured. Considering that the yaml files in question are not that huge, it should be good enough imho.
That would require an overall schema.
Which is why I suggested that the features that currently validate their own sections should register the syntax with the main code, which could piece it together.
It looks like the line number which is shown in parsing errors is relative to the part of the file that is checked by the individual features, making it all but useless.
Either remove the line number, or fix it so it relates to the entire file.