#coopt `dagger run` ?
humble garnet
I think given the small adoption of dagger run and the anticipated audience of zenith (10x larger conservatively, 1000x larger if we execute well 🙂 then it may be worth it. Using “am I inside an env” as the trigger is the missing piece of the puzzle IMO
Downside (besides breakage): doesn’t map entrypoint name
While we’re discussing crazy options: what if CLI and Shell were layered?
humble garnet
While we’re discussing crazy options: what if CLI and Shell were layered?
in other words: there’s a default shell; it’s populated by the environment CLIs. You invoke them with dagger shell -c or something
bonus points it gives @vast lance a playground to slowly introduce the scripting language of the future, whatever it ends up being (yeah i didn’t forget 😁)
dagger shell --lang bourne
dagger shell --lang graphql
dagger shell --lang bass ? 🙂
so we start with a simple “shlex” parser like buildkit uses, just word splitting nothing fancy
dagger shell -c “publish -v 0.2.3”
lament karma
in other words: there’s a default shell; it’s populated by the environment CLIs....
Yes I was thinking about this exact thing the other day 😁 I took a tiny baby step towards it by having dagger shell, if invoked w/ no args, drop you into a shell for the environment runtime container itself (which was mostly useful for debugging atm). But we can go much further w/ preloading all the env commands as actual invokable commands; maybe expose artifacts+checks in some way.
Basically, this shell would be the interactive manifestation of your environment, so to speak
humble garnet
or:
dagger shell
> publish -v 0.2.3
I like the idea of pluggable interpreter too
also, integration with our fancy interactive tui
humble garnet
Yes I was thinking about this exact thing the other day 😁 I took a tiny baby s...
yeah I saw that experiment pf yours which made me think of this, “shell manifestation of the env” is more useful than “drop you in the init container” IMO
lament karma
yeah I saw that experiment pf yours which made me think of this, “shell manifest...
oh totally, that was just a start which happened to be immediately useful too. Also, a similar idea would be to start a web server that gives you a gui for your environment and then proxy that to your localhost 
(I guess that in particular might have too much overlap with a cloud ui)
vast lance
I was about to type something and then re-read the scrollback and realized it's already what you're talking about 
I'm not sure where we would put the current meaning of dagger run. dagger exec comes to mind but that's probably confusing w/ docker exec and kubectl exec meaning something different.
But aside from that, I like the idea, since dagger run <env command> does feel like the more natural way to expose commands (you run them, you don't...do them)
vast lance
also, integration with our fancy interactive tui
Working on this now (dagger shell playing nice with our TUI)! It's a real stress-test of the vt100 implementation 😅 I have most things working but htop looks awful, there must be some ANSI sequences it's not handling correctly.
As part of this change I'm also removing the interactive parts of Progrock so there's no longer competition for keyboard input. The only key anyone uses is q anyway, and you can just use Ctrl+C instead like with any other CLI.
humble garnet
how do you feel about layering CLI/command over Shell?
ie merging dagger do into dagger shell
humble garnet
ie merging `dagger do` into `dagger shell`
btw if we did that, then the DX could fold command under shell if you see what I mean
vast lance
ie merging `dagger do` into `dagger shell`
yeah that's the part I was also going to suggest 🙂
humble garnet
so you’d have 2 kinds of ways to implement a shell:
- shells backed by a container
or - shells backed by individual commands
lament karma
btw if we did that, then the DX could fold `command` under `shell` if you see wh...
Yeah, I think it would be like the full syntax is dagger shell <cmd executed in the env context>, but the PATH would be preloaded such that all your commands are available
so then dagger shell publish calls your publish command because publish resolves to the binary implementing that
we'd still want to support what currently exists where you can define a shell entrypoint that is defined as a Container, but could probably make that work too somehow...
humble garnet
would have to be dagger shell -c publish or echo publish | dagger shell
lament karma
yeah or dagger shell -- publish, etc.
though at that point I'd argue it probably still makes sense to just rename shell->run
it would also make sense in that everyone already knows docker run, dagger run would be more or less the equivalent for us
Obviously with lots of differences in the details, but conceptually similar
e.g. we run environments rather than container image references
lament karma
Also, for Service entrypoints, it would be intuitive if dagger run --port <container port>:<localhost port> <the name of the service> resulted in the service running and forwarding the ports as specified.
With bikeshedding a better name than --port being a TODO 🙂
humble garnet
Also, for `Service` entrypoints, it would be intuitive if `dagger run --port <co...
I think up might be better for services, familiar to docker compose users
lament karma
I think `up` might be better for services, familiar to docker compose users
Yeah makes sense, dagger run for things that run synchronously, dagger up for background services
There's actually a ton of underneath-the-hood problems to solve to get an async service running beyond a single dagger ... cli call, but those are good problems to solve anyways
humble garnet
also this way you can dagger up and by default it brings all services up