Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

Idea: pkg/encoding/cue #423

Closed
mikelnrd opened this issue Jun 10, 2020 · 4 comments
Closed

Idea: pkg/encoding/cue #423

mikelnrd opened this issue Jun 10, 2020 · 4 comments
Labels
builtin FeatureRequest New feature or request

Comments

@mikelnrd
Copy link

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
//	...
//}
@mikelnrd mikelnrd added the FeatureRequest New feature or request label Jun 10, 2020
@verdverm
Copy link
Contributor

@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

#350 (comment)

@mikelnrd
Copy link
Author

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.

@mpvl
Copy link
Contributor

mpvl commented Jun 16, 2020

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.

@cueckoo
Copy link

cueckoo commented Jul 3, 2021

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

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

@cueckoo cueckoo closed this as completed Jul 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
builtin FeatureRequest New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants