cmd/cue: (eval|export) -l doesn't work for CUE input files

[rogpeppe]

commit e8550b89779d293bbc9b530d2c4c9f9cf4c6f3d0

exec cue export -l 'input:' x.cue
cmp stdout expect.json
-- x.cue --
x: "hello"
-- expect.json --
{
    "input": "x": "hello"
}

The input field isn't added to the top of the x.cue object:

> exec cue export -l 'input:' x.cue
[stdout]
{
    "x": "hello"
}
> cmp stdout expect.json
--- stdout
+++ expect.json
@@ -1,3 +1,3 @@
 {
-    "x": "hello"
+    "input": "x": "hello"
 }

FAIL: /tmp/testscript484054602/x.txtar/script.txt:2: stdout and expect.json differ
error running /tmp/x.txtar in /tmp/testscript484054602/x.txtar

testscript: exit exit status 1

[myitcv]

Confirmed with 8031fe7c. Appears to be a clear bug to me.

[mpvl]

-l is defined for making non-cue into a single cue namespace.

It was not designed with transformations in mind.

This could be considered given enough use cases and how this would interact with the other import options.

[mpvl]

To do actual transformations, I could imagine using the -e flag in combination with the query proposal to generate arbitrary transformed output.

[rogpeppe]

With the -e flag, is there any way of referencing the top level object currently?

[mpvl]

With the -e flag, is there any way of referencing the top level object currently?

There is not currently. But the -e flag would then use whatever convention used for the query syntax, which would also need to able to refer to the "current" object. I believe the current proposal this is @, with a second option being ..

@ is more verbose, but does not require a different syntax outside of relaxing identifiers. . is a bit trickier in that respect, which is why it is the less preferred option.