cue: cue: ResolveReferences option not work in method "Syntax"

_Originally opened by @leejanee in https://github.com/cuelang/cue/issues/867_

What version of CUE are you using (cue version)?

$ cue version
v0.3.0-beta.8

What did you do?

The code is as follows

       var src =`
t: {name: string}
output: [...t]
`
	var r cue.Runtime
	inst,_:=r.Compile("-",src)
	ct,_:=format.Node(inst.Value().Lookup("output").Syntax(cue.ResolveReferences(true)))
	fmt.Println(string(ct))

After running the code,I get

[...t]

But import the v0.2.2 version, The result is as follows

[...{
        name: string
}]

and, This is what i expected

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 39 (21 by maintainers)

Commits related to this issue

Most upvoted comments

Here you can find a first implementation: https://review.gerrithub.io/c/cue-lang/cue/+/541464/3.

There is a new test set where you can see some of the logic behind it.

Note that the current implementation assumes that whenever you pass a struct that is not the root, this behavior is desirable. I still need to distinguish between also closing over import references or not. So my current thinking is that there will be SelfContained option that is needed to expand references to imported packages (maybe ExpandImports is a better name). But that otherwise the use of the option is not necessary.

v0.4.1-beta.6

Very Good, It seems to satisfy our usage, next I will try to upgrade the cue version used in our project KubeVela. Also very much looking forward to the GA version.

#1816 one more case, maybe it’s also related with the selfcontained and can be resolved together.

It indeed solve it, to some extent, but please see my answer there. It may not solve it how you want it, but at least in principle it is able to solve it so it will not be hard to iterate towards something workable.

@leejanee @wonderflow please see v0.4.1-beta.6 (release notes to follow) as a first cut of a solution to resolve this issue. Please let us know what works/doesn’t work for you.

@wonderflow @fogdong just following up on the issues linked from above:

Replied in the issue. I’m not clear there is actually an issue here, just a bogus error value being reported. Perhaps you can confirm my understanding in the issue?

Commented in response to @mpvl. I think my conversation with @FogDong helped move this forward, but please let me know if there are any outstanding questions/issues.

Commented. You can work around this for now by casting a value of *cue.Context to *cue.Runtime.

We use cuelang to render kubernetes resources in kubevela. This process is divided into two stages:

  1. First, perform user-side rendering, the result is transmitted to the server in ast.Node format.
  2. Server-side rendering.

For example:

User 1 and User 2 cooperate to complete resource definition. User 1 define the resource type and default values, and user 2 focus on replicas

First of all, the template on the user side has a consistent format, for example as follows:

parameter: {
    ...
}

resource: {
   ...
}

the parameter is user input, and the resource is the desired resource definition.

  1. The template and input of user 1 is as follows:
----- template.file --------
import "k8s.io/api/core/v1"
parameter: {
    image: string
    replicas: int
}

resource: v1.#Deployment{
    spec: {
       replicas: parameter.replicas
       template: spec: containers: [{ 
                image: parameter.image
                name: "main"
                envs: [...]
        }]
    }
}

----- input.file --------
// set parameter
   image: *"myimage" | string
   // limit replicas scope 
   replicas: *2 | >=1 & <5
  1. The template and input of user 2(focus on replicas) is as follows:
----- template.file --------
parameter: {
    replicas: int
}

// not care about specific resource types here.
resource: {
   spec: replicas: parameter.replicas
}

----- input.file --------
// set parameter
replicas: 3

  1. on the server-side, process like as follows:
resource:  v1.#Deployment & { // user 1
     spec: replicas: *2 | >=1 & <5
     ...
} & {  // user 2
     spec: replicas: 3
}

I expect that the cue execution result on the user side can be recompiled on the server side again.

Morning, can we expect this fix in the next version? or is this blocked somehow? A new version of culang would improve the writing of templates in Kubevela very much 😃