docs: native scripting engine

[marshall007]

Description

See agenda from discussion with Zarf team for additional context, including a list of proposed API changes: https://docs.google.com/document/d/1KIrhFbUOzF9UA00axUbK7A4xrrtDdrBcjeKPLGNm65E/edit?pli=1#heading=h.lbxuy0bgvr5u

Related Issue

Fixes #

Relates to #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[zachariahmiller]

Assuming we go with risor i think it will be good to note that this doesnt actually limit the ability of using the other solutions that could be used today and as such is backwards compatible. It does however give us and our user much more flexibility in defining complex logic in the tasks and creating better, more reusable workflows that are more portable and dont rely on system specific tooling.

[Racer159]

Suggested change

	that actually improves portability of user-defined scripts.
	that actually improves portability of user-defined scripts without delegating to more complex paradigms like WASM.

(as Jeff Goldbloom says "life finds a way" and zx could be embedded but it would be quite annoying to do so)

[marshall007]

For the purposes of this proposal, we will scope the evaluation to libraries that can be embedded natively.

anything that is not written in Go would be difficult to integrate

I think the point stands as is. zx could not be integrated using WASM either because it relies on the Node.JS runtime. Your statement presents WASM as "complex" but similar to a native runtime, which it is not. It is just portable bytecode.

My point here was to scope the eval to Go-native runtimes. Otherwise, as you say, "life finds a way" and literally anything could be considered.

[Racer159]

I think one analysis missing here would be "health of ecosystem" - I would summarize that after a little digging as:

starlark-go and cel are both Google backed and have a good history of releases - starlet has one release and is backed by just one contributor - otto is backed by a single developer (San Francisco, CA) but does have a decently sized community / release history - risor is also backed by a single developer (Sterling, VA) and does have a decently sized community / release history.

cel is also not turing complete which could be a big downside for more complicated things one might want to do.

Probably the only real choices based on that are starlark-go, otto and risor and I do agree that raw starlark-go is limiting and while we could create an std lib with otto there would be a lot more wiring (we'd likely need an embed fs with node modules in it)

[marshall007]

Suggested change

	- [`starlark-go`](https://github.com/google/starlark-go), Go implementation
	of Starlark: Python-like language with deterministic evaluation and hermetic
	execution
	- [`starlet`](https://github.com/1set/starlet), which
	enhances the `starlark` runtime with useful extensions like `http`
	- expression languages like [`expr`](https://github.com/expr-lang/expr),
	[`cel`](https://github.com/google/cel-go) (which is used by Kubernetes[^4]),
	and [`cue`](https://github.com/cue-lang/cue)
	- [`otto`](https://github.com/robertkrimen/otto), a JS parser/interpreter
	written in Go
	These are all great, portable and secure options. However, with the exception
	of `starlet`, they are just language runtimes and lack rich APIs that we could
	expose directly to users. We would have to build these APIs ourselves from
	scratch.
	- [`starlark-go`](https://github.com/google/starlark-go), Go implementation
	of Starlark: Python-like language with deterministic evaluation and hermetic
	execution
	- [`starlet`](https://github.com/1set/starlet), which
	enhances the `starlark` runtime with useful extensions like `http`
	- expression languages like [`expr`](https://github.com/expr-lang/expr),
	[`cel`](https://github.com/google/cel-go) (which is used by Kubernetes[^4]),
	and [`cue`](https://github.com/cue-lang/cue)
	- [`otto`](https://github.com/robertkrimen/otto), a JS parser/interpreter
	written in Go
	These are all great, portable and secure options. However, with the exception
	of `starlet`, they are just language runtimes and lack rich APIs that we could
	expose directly to users. We would have to build these APIs ourselves from
	scratch.
	`starlark-go` and `cel` are both Google backed and have a good history of
	releases, but `cel` is a configuration language and not turing-complete.
	`starlet` has one release and is backed by just one contributor. `otto` is
	backed by a single developer (San Francisco, CA) but does have a
	decently sized community / release history.
	For our purposes, the only reasonable choices listed above would be
	`starlark-go` and `otto`.

[marshall007]

@Racer159 does this capture it?