Idea: pkg/encoding/cue

[cueckoo]

Originally opened by @mikelnrd in https://github.com/cuelang/cue/issues/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 https://github.com/cuelang/cue/issues/423#issuecomment-642287312

@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

https://github.com/cuelang/cue/issues/350#issuecomment-619291671

[cueckoo]

Original reply by @mikelnrd in https://github.com/cuelang/cue/issues/423#issuecomment-642637904

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 https://github.com/cuelang/cue/issues/423#issuecomment-644559668

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.