Idea: pkg/encoding/cue

[cueckoo]

Originally opened by @mikelnrd in cuelang/cue#423

Hi. Just throwing a slightly crazy idea out there in case it sticks... how about pkg/encoding/cue?

I believe cue (used as a pkg inside of cue) would fit the requirement of being hermetic:

All packages except those defined in the tool subdirectory are hermetic, that is depending only on a known set of inputs, and therefore can guarantee reproducible results. That is:

• no reading of files contents
• no querying of the file system of any kind
• no communication on the network
• no information about the type of environment
• only reproducible random generators

Use cases I can think of:

• testing cue code in cue (eg cue.Validate that works like yaml.Validate)
• cue examples in cue
• specifying cue constraints at runtime (small example below)
• ...

package idea

import (
	"encoding/cue"
)

#Example {
	cueConstraintFromUserAtRuntime: *'!= ""' | string
	name: string
	name: cue.UnMarshal(cueConstraintFromUserAtRuntime)
}

example: #Example & {
	name: "michael" 
}
example2: #Example & {
	cueConstraintFromUserAtRuntime: "^[a-z]{4}$" // any string with lowercase ASCII of length 4
	name: "mike" 
}

// Note that this in the same vein as google's cel common expression language which I guess could also fit into cue's stdlib somehow too...
//
//package idea
//
//import (
//	"encoding/cel" //https://github.com/google/cel-go
//)
//
//#Example {
//	celExpression: string
//	...
//}

[cueckoo]

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

@shykes convinced me having user defined functions is a bad idea because it means Cue can't evaluate all cue code anymore, effectively fracturing the ecosystem

cuelang/cue#350 (comment)

[cueckoo]

Original reply by @mikelnrd in cuelang/cue#423 (comment)

Ah yes that's a good point @verdverm. I don't have enough experience with cue or the roadmap to try to weigh in on the pros/cons of user defined functions but fracturing of the ecosystem doesn't sound good.

[cueckoo]

Original reply by @mpvl in cuelang/cue#423 (comment)

There definitely should be a package like this. The difficulty so far has been to come up with a good API: cue operates on both value and type level and the two sometimes need slightly different semantics. So coming up with good naming and/or options is a challenge. So this is mostly a design matter.