Options for scripting against aurae about aurae

[krisnova]

@bpmooch do you believe these features are mutually exclusive? I am sold on entertaining something like Deno... I also think having a CLI like buildah where we can easily use it with bash also makes sense.

In other words... why not both?

[dmah42]

if the language is meant to wrap around the gRPC API, then either a custom language or a gRPC-supported language are likely options. ie, either auraescript as a custom wrapper around the gRPC client to reduce verbosity/improve readability or python/go/java(!) acting as a client directly.

i'm not sure bash or lua fits the bill unless there are gRPC client implementations i'm not aware of.

but the question of "why auraescript?" is a good one to probe.

[bpmooch]

i'm not sure bash or lua fits the bill unless there are gRPC client implementations i'm not aware of.

Sorry for not being clear - I'm proposing a cli similar to buildah, which has a goal of replacing dockerfiles with bash scripts. I'm basically saying that I don't see the need for auraescript because a gRPC API wrapper cli written in rust (or whatever) seems to do the job great and avoids a lot of complexity in maintaining a Rhai implementation.

If auraescript's intent was to heavily utilize the integration of the scripting language with aurae (such as Rhai's bespoke Rust integrations), then Deno seems a more compelling choice to me

[krisnova]

@bpmooch would you be interested in starting a deno-based auraescript? or even a buildah style CLI tool? we can see which ones end up growing if we are interested in taking the "why not both" approach?

[bpmooch]

@krisnova back at keys after vacation, yea I'm interested in working on this. I'll try to get some notes into the architecture repo soonish

[krisnova]

Hey @bpmooch we just had an interesting thought from @GANitak

What if we added Deno "on top" of the Rhai library?

We know we will need to build out an opinionated client in rust (something that looks for configuration files in a well known place and understands what an aurae socket is) as well as the basic client functions anyway.

Couldn't we just map the client functions directly into Deno as well? Or at least slowly move them over in the lib.rs file to Deno? Unsure if you have an approach in mind? I am open to whatever you want to do and am already convinced Deno is a good move for the project.

Basically I would like to be able to move forward with testing against the daemon right now, without blocking on the Deno work.

[krisnova]

The work in #115 will close this issue as it will introduce Deno as the primary core for AuraeScript and make AuraeScript 100% compatible with TypeScript and JavaScript.

This was a fantastic idea.

[future-highway]

Closing as of #120