Placeholder for old PR #841

[cueckoo]

Originally raised by @morlay in cuelang/cue#841

[cueckoo]

Original reply by @verdverm in cuelang/cue#841 (comment)

For reference, this topic came up about a year ago. cuelang/cue#350 (there was more in slack)

The TL;DR is that there is concern about fracturing the ecosystem.

If you add custom builtins, then you cannot read or process your Cue with the Cue CLI (reference implementation). This in effect creates dialects that only your tool can process. This may be ok for you and your tool, however, were this to happen with many tools, then people see examples of "Cue" from these many tools, ( each with their own dialect ), then people get confused about "Why does this Cue that I see over there does not work here? Why is the Cue CLI telling me this doesn't exist?" So if you make a tool that creates a dialect of Cue, it might not really be Cue anymore depending on who you ask.

There are a few existing capabilities and proposals that may make help you:

• The text/template package means you can create any file in any format or language
• Attributes are available to tools using the Cue API (from Go), the Cue CLI already has a few defined for its use
• cue mod will make dependencies and their imports really easy
• The "function" sugar issue (proposal?) that you already linked to
• Open an issue to support the ini format and see where that is said about that (not familiar enough with the complexities to comment myself)

[cueckoo]

Original reply by @morlay in cuelang/cue#841 (comment)

@verdverm I know your concerns.
sometimes, we need to create custom tool to make our work easier, before offical provided.

I'm not care how many tools i have to use, but if I want to bring a new good thing (cuelang is cool) to my team.
I need to make sure it could simple enough, and a single binary will be the best.

Recently, I'm bringing my team to get away from helm,
starts with using jsonnnet/tanka, but without type constraints, jsonnet can't not stop people make mistakes.

So i start to create a new tool to solve my problems base the cuelang - https://github.com/octohelm/cuemod

Totally copy features from go modules.
Instead of throughing go get to download.
cuemod could download deps, and save the deps info into mod.cue.

With adding new life cycle before mod load,
the registered extractors could automately extract from source codes to cue codes.

I hope the workflow could be easy like:

mkdir -p ./demo && cd ./demo

cat << EOT > kube.cue
package kube

import (
   apps_v1 "k8s.io/api/apps/v1"
)

deployment: [string]: apps_v1.#Deployment

_labels: { "app": "nginx" }

deployment: nginx: spec: selector: matchLabels: _labels
deployment: nginx: spec: template: metadata: labels: _labels
deployment: nginx: spec: template: spec: {
	containers: [{
		name: "nginx"
		image: "nginx:1.11.10-alpine"
	}]
}
EOT
 
cuem eval ./kube.cue

And now, I have lots of helm charts and jsonnet. I can't refactor all of them to cue.

JSONNET: https://github.com/octohelm/cuemod/blob/main/pkg/cuemod/testdata/b/jsonnet_demo/jsonnet.cue
Helm Charts: https://github.com/octohelm/cuemod/blob/main/pkg/cuemod/testdata/b/helm_simple/local-path-provisioner.cue

This why the PR here. I really need add custom pkg to make it works in cue before i refactored.
text/template can't resolve it.

using Attributes may could do this too, but I don't know how to use Attributes to convert other format data to cue values.

[cueckoo]

Original reply by @morlay in cuelang/cue#841 (comment)

@verdverm

I think i could write a custom MarshalJSON to replace the cue.Value which with special tag.
to avoid to added custom functions

package kube

import "encoding/json"

config_map: xxx: spec: data: "xxx.toml":  json.Marshal({}) @manifest("toml")
config_map: xxx: spec: data: "xxx.ini":  json.Marshal({}) @manifest("ini")

app_from_helm: { 
    @helm() 
    
    values: {} 
    files: {} 
} 

app_from_jsonnet: { 
    @jsonnet()
    
    data: ''
    imports: {} 
}

But the decl attrs. seems have to wait cuelang/cue#529

[cueckoo]

Original reply by @myitcv in cuelang/cue#841 (comment)

@morlay thanks for starting a discussion on this. Generally speaking it's preferable to open a GitHub issue/discussion before a PR/Gerrit change (the Go project follows a similar model). PRs/Gerrit changes can easily follow later, once we have agreed and fleshed out a design and direction. If there isn't an issue that corresponds well to what you're after, please feel free to open a new one. Thanks

[cueckoo]

Original reply by @morlay in cuelang/cue#841 (comment)

@verdverm i follow your suggestions. It works. https://github.com/octohelm/cuemod#post-processing-translatename.
I could create my own tool without forking cue codes.

Only a limit here, we can't use the translated results in cue any more.
However, in my usages, it could be fine.