cmd/cue: get go misses an embed?

[nyarly]

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

$ cue version
0.3.0-beta.6

What did you do?

> cue get go sigs.k8s.io/kustomize/api/builtins

What did you expect to see?

A working Kustomize ConfigMapGenerator
c.f. https://cuelang.org/play/?id=d_RzGK2DVVt#cue@export@cue

The issue is that cue get go pulled in the (go) embedded types.ConfigMapArgs as an explicit sub-struct, when it should be an embedded definition

[verdverm]

I think the issue is likely around here: https://github.com/cuelang/cue/blob/master/cmd/cue/cmd/get_go.go#L1010 because the original source crosses package boundaries (i.e. requires an import)

Not sure if the (lack of) Go struct tags is playing into this... I'm curious about the sibling metadata field which is

• also embedded in the original source
• also crosses package boundaries
• also has a label in the generated output
• but does have a struct tag which supplies a name

So perhaps it is because the original source lacks the struct tag for ConfigMapArgs?

[myitcv]

Firstly, it would be helpful to have a full repro in cases like this to ensure anyone looking at this problem is looking at exactly the same types etc. Reason being, we're talking about a Go dependency here, hence we might be looking at subtly different versions of that dependency. The wiki gives details on how to provide such reproducers. For example, my attempt to repro this involved constructing a go.mod (that describes the dependency) as follows:

go mod init mod.com
cue mod init mod.com
cat <<EOD > cue.go
// +build cue

package cue

import (
	_ "sigs.k8s.io/kustomize/api/builtins"
)
EOD
go get -d sigs.k8s.io/kustomize/api/builtins@v0.8.5
go mod tidy

This resulted in:

-- cue.go --
// +build cue

package cue

import (
	_ "sigs.k8s.io/kustomize/api/builtins"
)
-- cue.mod/module.cue --
module: "mod.com"
-- go.mod --
module mod.com

go 1.16

require sigs.k8s.io/kustomize/api v0.8.5

At which point I then ran:

cue get go sigs.k8s.io/kustomize/api/builtins

which gave me:

$ cat cue.mod/gen/sigs.k8s.io/kustomize/api/builtins/ConfigMapGenerator_go_gen.cue
// Code generated by cue get go. DO NOT EDIT.

//cue:generate cue get go sigs.k8s.io/kustomize/api/builtins

package builtins

import "sigs.k8s.io/kustomize/api/types"

#ConfigMapGeneratorPlugin: {
        metadata?:     types.#ObjectMeta @go(ObjectMeta) @protobuf(1,bytes,opt)
        ConfigMapArgs: types.#ConfigMapArgs
}

which is what I believe we are talking about here.

explicit sub-struct,

I'm not entirely clear what you mean here, but I assume this is a reference to the fact that the generated CUE for ConfigMapGeneratorPlugin has fields metadata and ConfigMapArgs in contrast to the corresponding Go type where they are embedded:

type ConfigMapGeneratorPlugin struct {
	types.ObjectMeta `json:"metadata,omitempty" yaml:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
	types.ConfigMapArgs
	// contains filtered or unexported fields
}

This appears to be working as documented, from cue help get go:

Go structs are converted to cue structs adhering to the following conventions:

        ...

        - embedded structs marked with a json inline tag unify with struct
          definition. For instance, the Go struct

            struct MyStruct {
                        Common  json:",inline"
                        Field string
                 }

          translates to the CUE struct

                 #MyStruct: Common & {
                         Field: string
                 }

        ...

In this case neither field is marked with inline.

[myitcv]

Despite having marked this as "working as intended", this issue does raise a broader point that I discussed with Marcel some time ago. Namely what semantics should cue get go use for embedding types. I'm going to create a separate issue for that.

[verdverm]

In this case, based on how the YAML looks and the desire to cue import go and then cue vet with the generated CUE, revisiting the semantics sounds great!

[cueckoo]

This issue has been migrated to cue-lang/cue#848.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.