Produce valid TOML for non-map root values

[guilherme-puida]

A document like the one below (or anything that is not a key-value pair):

123

is not valid TOML. This PR fixes this by making it a key-value pair instead.

value = 123

Do note that this is a breaking change, but I guess this is fine since the previously emitted documents were just invalid.

I chose value here arbitrarily, it could be changed to another key. This fixes #550, and also bumps to-toml to the latest version.

[TomWright]

Hey @guilherme-puida , I missed this and opened this PR.

Happy to take your contribution if you could update the root value handling here to exclude value = so the test assertions don't need to change to this newStringWithFormat(toml.TOML, value = true),?

[guilherme-puida]

By excluding "value = ", dasel would produce invalid TOML documents. For example, when running on current master:

% echo 1 | ./dasel -i json -o toml --root | tee >(python -c 'import tomllib, sys; print(tomllib.load(sys.stdin.buffer))')
1
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import tomllib, sys; print(tomllib.load(sys.stdin.buffer))
                               ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/tomllib/_parser.py", line 133, in load
    return loads(s, parse_float=parse_float)
  File "/usr/lib/python3.14/tomllib/_parser.py", line 174, in loads
    pos = key_value_rule(src, pos, out, header, parse_float)
  File "/usr/lib/python3.14/tomllib/_parser.py", line 403, in key_value_rule
    pos, key, value = parse_key_value_pair(src, pos, parse_float)
                      ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/tomllib/_parser.py", line 443, in parse_key_value_pair
    raise TOMLDecodeError("Expected '=' after a key in a key/value pair", src, pos)
tomllib.TOMLDecodeError: Expected '=' after a key in a key/value pair (at line 1, column 2)

And on this branch:

% echo 1 | ./dasel -i json -o toml --root | tee >(python -c 'import tomllib, sys; print(tomllib.load(sys.stdin.buffer))')
value = 1
{'value': 1}

Is this really what is expected? I would assume that dasel always emits valid TOML documents.

[TomWright]

It's a fair question, and you are right about the output not being directly readable by a TOML parser, but I'm cautious of anyone already using a toml output with a single value and this change breaking their pipelines.

Quite often people look to extract the value itself without any TOML document for use with other scripts, or even for use in another dasel executable.

I am torn though since ini, hcl and csv writers already have requirements around the output data.

[guilherme-puida]

It's a fair question, and you are right about the output not being directly readable by a TOML parser, but I'm cautious of anyone already using a toml output with a single value and this change breaking their pipelines. Quite often people look to extract the value itself without any TOML document for use with other scripts, or even for use in another dasel executable.

Hm, this makes sense. I didn't consider this usecase. Something like `echo 'value = 1' | dasel -i toml '$root.value'` would just echo back the input instead of outputting just `1`.

I am torn though since ini, hcl and csv writers already have requirements around the output data.

Tough spot. IMHO it would be nice to make this consistent: always output a valid document in the format requested, but I understand if you want to keep the current behavior instead. Feel free to close this if you decide to go that route.

[TomWright]

I think we can take the middle road. If you could keep the current (incorrect) behaviour in-place, then open up a new PR with the change. We can let the people raise any issue they have with it, otherwise let it go in.

I do need to create a "plain" output writer which could substitute the problematic use-case I mentioned above in the future.

[guilherme-puida]

I think we can take the middle road. If you could keep the current (incorrect) behaviour in-place, then open up a new PR with the change. We can let the people raise any issue they have with it, otherwise let it go in.

Might be easier to merge #553 first, then I'll adapt this PR to just introduce the value = ... behavior (essentially reverting the changes from that PR).

I do need to create a "plain" output writer which could substitute the problematic use-case I mentioned above in the future.

+1

[TomWright]

OK will do, thanks.

I've just merged the plain output writer to set this PR up for success