On Sun, 26 Mar 2017 13:04:18 -0700 Brian Dolbec <[email protected]> wrote:
> While this can be read and split easily in python code. It
> is not future proof for additional data being added and/or removed.
This is why in my earlier comments to this proposal, I asked for
a: more descriptive terms than 'stable', 'unstable', or 'testing', because
they're
all contextually ambiguous without inherently clear meaning
b: a format of <index>\s<fields> where <fields> was a list of space-delimited
<key>=<value> pairs.
This at least means we stop relying on columns for data, and means that the data
is also trivially parseable with simple tools like grep/sed.
Whereas defining it as a multi-line YAML parser may seem great if you can
assume every tool at users disposal has YAML parsers and standard YAML parsing
libraries,
but in reality, some of the tools at our disposal are "bash" and "sed", and
decoding
and interpreting YAML from Bash is rather complicated.
( And there are other fun problems when you start talking about YAML )
Though, you could cheat and mandate a packed 1-line-per-arch YAML format.
This, iirc, is legal YAML:
amd64: {stability: "stable", bits: 64, description: "Includes CPU manufaturers
such as Intel, AMD, others...", comments: "The most common/popular arch in the
tree...", email: "amd64@..." }
But at that point ...
s/\b(([^=]+=(\S+)\b/{$1: "$2"}, / && parse_yaml ...
pgpdEA_DotYpR.pgp
Description: OpenPGP digital signature
