Conversation starter - scripting snippet

[lofty notch]

I quite like this 🙂 It feels a little bit like the cli... but with more things. Also a scripting language like this implies a REPL! A dagger repl would honestly be incredible, to kind of interactively build your artifacts (and if we have the examples generation tooling, we could also take the resulting dagql ids/graphql snippets and generate a project from a repl session).

I am biased, I like building and working on DSLs. I am curious (from your perspective) - why is this approach different from something like CUE, which we've previously stopped working on?

[native jay]

one major difference is that this is bash-compatible syntax

so there is no custom DSL involved

[lofty notch]

so is this running bash under-the-hood, or are we implementing a shell ourselves / pulling an off-the-shelf implemetation?

i like shells a lot, but they can be very tricky to implement (if you aim for near-POSIX compatability)

from an architectural perspective, if we do take an approach like this, i'd like to see if we can have the scripting side live as a separate component. it would be really cool if other users could build their own scripting languages (e.g. i could definitely imagine @finite loom building a bass one)

[finite loom]

I did start on one but it's been on the backburner for a while - the parser is done, and it has type checking + loading types from GraphQL, but no interpreter yet. Aim was to have its syntax match the syntax shown in the TUI and in Cloud: https://github.com/vito/dash

...but yeah, it's a whole DSL to learn, so not really in the spirit of this thread.

For this thread I would imagine it's actually "just Bash" but with pre-installed functions that map to the Dagger API somehow. Personally I'd rather keep type checking and a sane language to work in assuming there's minimal overhead and it feels like I'm just gluing together Dagger APIs - but I can definitely see the argument for "it's just Bash"

[grizzled wasp]

I'd suggest not inventing yet another way to interact with Dagger as code. We have code options. Adding a YAML or JSON interface for "simple" pipelines feels like it could add value, but isn't the Dagger Script approach just another code choice?

[severe osprey]

On one hand, this snippet feels to provide better interop between Dagger config and the actual work to be executed.
Unlike Golang, where it sometimes feel a bit strange to do a ton of set-up of Containers etc. to execute a bunch of CLI commands - or even a *sh script.

On the other hand, while it is not a DSL, I do imagine that some kind of SDK would be built on top in order to get better a better feedback loop - i.e. IDE diagnostics rather than CLI error output.

I see a high value in this, if the purpose was to wrap an existing *sh command or script, just to lock the dependencies/environment along with the logic - perhaps utilize other Dagger features like parameterization.
Or perhaps just for creating simple modules/functions in a very concise manner.