kas dump yaml file structure order #118
Comments
|
Hi @embetrix , despite the changed order, both the input and the combined output should be semantically identical. If not, this is a bug. As kas internally represents the configuration as a python dict, the order is currently not preserved. Do you have a use-case where preserving the order is required (or desired)? Ideally, you could also bring this topic up on the mailing list ([email protected]), as we have a broader audience there. |
|
@fmoessbauer I agree that the semantic and usage are identical even the order has changed. |
|
I think that kas dump is sorting the yaml keys alphabetically, I believe it can be turned off. |
By that I expect to get a rather stable ordering. Without sorting, the keys are likely at nondeterministic positions, which makes thinks even more unstable. At least for json there is a "canonical" format that is stable (keys are sorted, no whitespacing). I don't know if a similar standard also exists for yaml. This however, is likely not the solution you are looking for. |
|
maybe as an option parameter for kas dump : do not sort ? |
|
If the kas-example.yml at the beginning is configured in dictionary order, then the layout of kas-example-fixed.yml will not be so different. lol |
|
@gowufang I re-checked the code and actually found the inconsistency. When doing |
The yaml and json formatter differed w.r.t sorting the keys during serialization (json kept the order, yaml sorted). As pointed out in siemens#118 the users expect to maintain the order of the keys. By that, we make this the new default and add an CLI option "--sort" to sort the output. Closes: siemens#118 Signed-off-by: Felix Moessbauer <[email protected]>
The yaml and json formatter differed w.r.t sorting the keys during serialization (json kept the order, yaml sorted). As pointed out in siemens#118 the users expect to maintain the order of the keys. By that, we make this the new default and add an CLI option "--sort" to sort the output. Closes: siemens#118 Signed-off-by: Felix Moessbauer <[email protected]>
The yaml and json formatter differed w.r.t sorting the keys during serialization (json kept the order, yaml sorted). As pointed out in siemens#118 the users expect to maintain the order of the keys. By that, we make this the new default and add an CLI option "--sort" to sort the output. Closes: siemens#118 Signed-off-by: Felix Moessbauer <[email protected]>
The yaml and json formatter differed w.r.t sorting the keys during serialization (json kept the order, yaml sorted). As pointed out in siemens#118 the users expect to maintain the order of the keys. By that, we make this the new default and add an CLI option "--sort" to sort the output. Closes: siemens#118 Signed-off-by: Felix Moessbauer <[email protected]>
The yaml and json formatter differed w.r.t sorting the keys during serialization (json kept the order, yaml sorted). As pointed out in siemens#118 the users expect to maintain the order of the keys. By that, we make this the new default and add an CLI option "--sort" to sort the output. Closes: siemens#118 Signed-off-by: Felix Moessbauer <[email protected]>
The yaml and json formatter differed w.r.t sorting the keys during serialization (json kept the order, yaml sorted). As pointed out in siemens#118 the users expect to maintain the order of the keys. By that, we make this the new default and add an CLI option "--sort" to sort the output. Closes: siemens#118 Signed-off-by: Felix Moessbauer <[email protected]>
There is a subtle bug in the IncludeHandler that makes the config either a dict or an OrderedDict. If a single config is provided (that also means no lockfile), the raw result of the config parser is taken, which is a dict (since Python 3.6). If any merging operation of multiple configs is performed, this is converted into a OrderedDict, as otherwise the order of the keys is not preserved for Python < 3.6. As we only support Python 3.6+, this bug likely does not have any influence on the semantics of the config, but it does lead to inconsistent results when dumping the config again (as reported in siemens#118). An OrderedDict is always serialized in order, a standard dict is sorted if not specified otherwise. This also affected the pretty-printed merged config on debug. Instead, we now solely rely on the preserved include order of Python dicts from Python 3.6 on (in 3.6 it is a implementation detail, later it became part of the spec). From Python 3.6 on there is no reason to use OrderedDict anymore, so better avoid it to be more robust when interfacing with other libraries (like json, pyyaml). Signed-off-by: Felix Moessbauer <[email protected]>
There is a subtle bug in the IncludeHandler that makes the config either a dict or an OrderedDict. If a single config is provided (that also means no lockfile), the raw result of the config parser is taken, which is a dict (since Python 3.6). If any merging operation of multiple configs is performed, this is converted into a OrderedDict, as otherwise the order of the keys is not preserved for Python < 3.6. As we only support Python 3.6+, this bug likely does not have any influence on the semantics of the config, but it does lead to inconsistent results when dumping the config again (as reported in siemens#118). An OrderedDict is always serialized in order, a standard dict is sorted if not specified otherwise. This also affected the pretty-printed merged config on debug. Instead, we now solely rely on the preserved include order of Python dicts from Python 3.6 on (in 3.6 it is a implementation detail, later it became part of the spec). From Python 3.6 on there is no reason to use OrderedDict anymore, so better avoid it to be more robust when interfacing with other libraries (like json, pyyaml). Signed-off-by: Felix Moessbauer <[email protected]>
There is a subtle bug in the IncludeHandler that makes the config either a dict or an OrderedDict. If a single config is provided (that also means no lockfile), the raw result of the config parser is taken, which is a dict (since Python 3.6). If any merging operation of multiple configs is performed, this is converted into a OrderedDict, as otherwise the order of the keys is not preserved for Python < 3.6. As we only support Python 3.6+, this bug likely does not have any influence on the semantics of the config, but it does lead to inconsistent results when dumping the config again (as reported in #118). An OrderedDict is always serialized in order, a standard dict is sorted if not specified otherwise. This also affected the pretty-printed merged config on debug. Instead, we now solely rely on the preserved include order of Python dicts from Python 3.6 on (in 3.6 it is a implementation detail, later it became part of the spec). From Python 3.6 on there is no reason to use OrderedDict anymore, so better avoid it to be more robust when interfacing with other libraries (like json, pyyaml). Signed-off-by: Felix Moessbauer <[email protected]> Signed-off-by: Jan Kiszka <[email protected]>
kas-example.yml:
kas dump --resolve-refs kas-example.yml > kas-example-fixed.ymlkas-example-fixed.yml:
would be possible to keep the same original structure for kas-example-fixed.yml?:
The text was updated successfully, but these errors were encountered: