-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: native scripting engine #112
base: main
Are you sure you want to change the base?
Conversation
3bcdf9b
to
cf99b0c
Compare
|
||
|
||
## Consequences | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Tools like [`zx`](https://google.github.io/zx/getting-started) | ||
(which provides a JS API on top of shell scripting) are interesting, but | ||
anything that is not written in Go would be difficult to integrate in a way | ||
that actually improves portability of user-defined scripts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- [`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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- [`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`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Racer159 does this capture it?
Co-authored-by: Wayne Starr <Racer159@users.noreply.github.com>
Description
...
Related Issue
Fixes #
Relates to #
Type of change
Checklist before merging