Toml

[andrewgsavage]

• Closes # (insert issue number)
• Executed pre-commit run --all-files with no errors
• The change is fully covered by automated unit tests
• Documented in docs/ as appropriate
• Added an entry to the CHANGES file

[andrewgsavage]

this is where I've got to on a toml parser @jules-ch

[codspeed-hq]

CodSpeed Performance Report

Merging #2133 will not alter performance

_{Comparing andrewgsavage:toml (38e32f7) with master (384b346)}

Summary

✅ 447 untouched benchmarks

[andrewgsavage]

I need to set up the tests we do for .txt for .toml too. This is mostly ready for review, with the following things to consider:

• the toml file gets read into a dict. Should we accept a dict to initialise the registry too?
• there are redefinition warnings for group or systems units, haven't worked out why. I wonder if I am defining them twice in the toml file, in the main and in the group.
• the writer uses an external library to write a toml file. Should this be an optional dependency?
• I've added a function to the registry to write a toml file. I imagine a function returning a dict could be useful too

[jules-ch]

Can we use inline tables, that simplify the toml structure quite a lot.

example for prefix:

[prefix]
quecto = { value = "1e-30", defined_symbol = "q" }
ronto  = { value = "1e-27", defined_symbol = "r" }
yocto  = { value = "1e-24", defined_symbol = "y" }
zepto  = { value = "1e-21", defined_symbol = "z" }
atto   = { value = "1e-18", defined_symbol = "a" }
femto  = { value = "1e-15", defined_symbol = "f" }
pico   = { value = "1e-12", defined_symbol = "p" }
nano   = { value = "1e-9", defined_symbol = "n" }
micro  = { value = "1e-6", defined_symbol = "µ", aliases = ["μ", "u", "mu", "mc"] }
milli  = { value = "1e-3", defined_symbol = "m" }
centi  = { value = "1e-2", defined_symbol = "c" }
deci   = { value = "1e-1", defined_symbol = "d" }
deca   = { value = "1e+1", defined_symbol = "da", aliases = ["deka"] }
hecto  = { value = "1e2", defined_symbol = "h" }
kilo   = { value = "1e3", defined_symbol = "k" }
mega   = { value = "1e6", defined_symbol = "M" }
giga   = { value = "1e9", defined_symbol = "G" }
tera   = { value = "1e12", defined_symbol = "T" }
peta   = { value = "1e15", defined_symbol = "P" }
exa    = { value = "1e18", defined_symbol = "E" }
zetta  = { value = "1e21", defined_symbol = "Z" }
yotta  = { value = "1e24", defined_symbol = "Y" }
ronna  = { value = "1e27", defined_symbol = "R" }
quetta = { value = "1e30", defined_symbol = "Q" }

kibi   = { value = "2**10", defined_symbol = "Ki" }
mebi   = { value = "2**20", defined_symbol = "Mi" }
gibi   = { value = "2**30", defined_symbol = "Gi" }
tebi   = { value = "2**40", defined_symbol = "Ti" }
pebi   = { value = "2**50", defined_symbol = "Pi" }
exbi   = { value = "2**60", defined_symbol = "Ei" }
zebi   = { value = "2**70", defined_symbol = "Zi" }
yobi   = { value = "2**80", defined_symbol = "Yi" }

semi   = { value = "0.5", aliases = ["demi"] }
sesqui = { value = "1.5" }

[andrewgsavage]

Can we use inline tables, that simplify the toml structure quite a lot.

looks doable if I swap to tomlkit for writing

[jules-ch]

For the writer, options are vendoring or specifying an extra dep.

Using the writer is only used for serializing a Registry as file no ?
For migration and stuff like that ?

We could talk about the toml spec and provide a json schema for linting but that's for another PR I suppose.

[andrewgsavage]

For the writer, options are vendoring or specifying an extra dep.

Using the writer is only used for serializing a Registry as file no ? For migration and stuff like that ?

We could talk about the toml spec and provide a json schema for linting but that's for another PR I suppose.

actually I could remove the writer and just return a dict. let the user install a toml writer and write it to file.

yea it's just for migrating from current .txt format

the first module I tried lost ordering ( didn't place all attributes for a definition together).