@tag --inject equivalent in yaml used by kpt tool is a magic comment #Ref

[cueckoo]

Originally opened by @mikelnrd in https://github.com/cuelang/cue/issues/422

Hi. Google's new kpt tooling for kubernetes does an interesting thing where it uses special #Ref comment in yaml files to mark where a 'setter' is. This allows other downstream importers of a kpt package to set a value.

I saw this today and immediately thought of cue's @tag and --inject functionality.

I just thought I'd flag this to the cue developers... if kpt tooling becomes prominent in the ecosystem (which it might as its from Google and is designed to compose with other tools), might it be useful/worth considering having cue support reading/writing magic comments like #Ref?!

More context...

kpt cfg create-setter express-web/ replicas 3

replicas: 3 # {"$ref":"#/definitions/io.k8s.cli.setters.replicas"} 

kpt cfg set express-web replicas 2

This article looks like it explains kpt and the purpose of the #Ref comments quite well: https://labs.meanpug.com/kubernetes-kpt-in-the-wild/

More generally it seems to me (from the outside) that kpt and cue are working in a similar area. I can see why both should exist and even work together (you can pry cue from my cold dead hands as the saying goes) - I guess I'm wondering if there's been much communication between those working on the two projects so far??

[cueckoo]

Original reply by @seh in https://github.com/cuelang/cue/issues/422#issuecomment-642183263

While I don't like that these $ref comments can only sit in comments today—and hence rule out conveying them in JSON—I do appreciate some things about kpt, and how it integrates running functions to manipulate manifests. I too have been exploring how to knit CUE and kpt together, and can't quite figure out which one belongs "inside" versus "outside" (which makes me think of peanut butter and chocolate).

CUE says, "Don't build tools that call CUE; have CUE call your tools, or have CUE be your tools," or something like that. kpt says, "Package your tools and have kpt call them," or "Run your tools and pipe them to kpt."

I can't figure out I should have a CUE _tool.cue file calling on kpt, or treat CUE as a kpt function, or maybe get Bazel involved to glue them together in some other way.

[cueckoo]

Original reply by @verdverm in https://github.com/cuelang/cue/issues/422#issuecomment-642290235

I'm strictly avoiding adopting any new tools which still use yaml. Accomplishing what they do with Cue and a bit of Go is so easy, I'm more convinced Cue is going to sweep through DevOps tooling. I haven't looked at kpt but it sounds like it's going the direction of Pulumi and wrapping data / config with code (opposite of Cue's philosophy). I actually came to Cue when I had hacked imports into Yaml using comments. Using comments for logic just seems like a terrible idea, went there myself and left very quickly.

@seh can you point us at the quote about not building tools that call Cue?

I'm building tools on top of Cue and invoke Cue in various places with other tools. Attributes are amazing and only accessible in tools build on Cue. I have used the _tool.cue for some simple things but find I prefer writing Go code which imports Cue as a module and effectively uses Cue's runtime internally. There are just so many more possibilities this way, and I'm using Cue to generate the majority of CLI implementations now (https://github.com/hofstadter-io/hofmod-cli).

About your original in/out-side, I'm finding I prefer having Cue or a tool built around Cue at the top, and driving all other programs from there. Cue's philosophy is generally to wrap code in data and I'm starting to see why this is a good philosophy.

[cueckoo]

Original reply by @seh in https://github.com/cuelang/cue/issues/422#issuecomment-642635768

Unlike Pulumi, kpt is much closer to CUE: It wants to wrap around the transforming tools, so that you tell kpt how and when to run which tools to process the JSON or YAML documents. It's a little hard to figure out whether kpt considers these functions to be operating on text or on "objects". In the normal case it's passing YAML documents through them, but there are expectations about validity and preserving comments, so it's a more "structured" approach than a tool like Helm's ransom note style of cobbling together text fragments that might come together as valid YAML.

The telegraphed quotation about not building tools that call CUE comes from the "Define commands" section of the Kubernetes tutorial. I thought I had seen more of this advice elsewhere, but can't find it in a cursory search this morning.

Here's a key paragraph:

In practice this means typing the same commands ad nauseam. The next step is often to write wrapper tools. But as there is often no one-size-fits-all solution, this lead[s] to the proliferation of marginally useful tools. The cue tool provides an alternative by allowing the declaration of frequently used commands in CUE itself. Advantages:

You mention the philosophy of "wrap[ping] code in data". It's not clear to me yet how that's either advantageous or sufficient. Tools like Bazel go in that direction, though not every problem is amenable to modeling in terms of input files, dependencies, and output files. Can you elaborate on what's bad about the antonym—presumably "wrapping data in code"?

[cueckoo]

Original reply by @mpvl in https://github.com/cuelang/cue/issues/422#issuecomment-701479931

sorry, closed wrong bug.