#CLI, all-in-one or client only?

1 messages · Page 1 of 1 (latest)

sly musk
#

Thread here

languid carbon
#

Are there pros/cons other than the separation of concerns? I'm used to the hashicorp single-binary model which has always felt natural to me

sly musk
#

I need to right them all out, right now it's more of a pattern / gut feeling from several threads coming together...

#

Just off the top of my head:

  • There are 4 quite different functions ot bundle in the same binary (not to mention buildkit which is a 5th). That's a lot.
  • Ambiguity on terminology: what is the "engine": is it the CLI? or the server/worker part of the CLI?
  • Complexity on the packaging and release side
#

@languid carbon what's a good comparison point in the hashicorp world?

languid carbon
#

In my mind pretty much any of vault https://www.vaultproject.io/docs/commands, consul, boundary, nomad. In each of those cases, the one binary does all the things from server, worker, client, utility, etc.
One commonality that stands out to me is that in a lot of cases one context (machine) will commonly need to serve two or more of those purposes.

A contrasting example would be terraform. The cli is purely a client. Terraform enterprise (the server) is distributed exclusively as OCI images (yes, multiple images)

sly musk
#

One extra benefit of shipping the engine as an OCI image, is that it acts as a repellant for the usual leeches - repackaging / forking by Red Hat and other distros etc. They can only do that with binary tools. If the source of truth is an OCI image, then we don't have to worry as much about people getting broken or unofficial builds

languid carbon
#

Does the engine get shipped as an OCI whether the cli gets split up or not, or does that packaging only exist if the cli does get split up?

sly musk
#

I think it will exist either way

languid carbon
#

Ok. In that case I think the only question I would have is: is there a reasonable case where I want to consume the engine in a way that isn't this OCI? and if not then ship it

sly musk
#

Right now the answer is "not sure, maybe?" but I think the answer should be "no". If you can't run OCI containers, the engine won't work anyway

languid carbon
#

As long as we ship the appropriate base images for whatever org restrictions

sly musk
#

(right now there's only the "all in one binary" option)

sly musk
#

as a complete black box

languid carbon
#

Yeah perfect

sly musk
#

One piece of this puzzle is what kind of client experience we want for dagger. I feel like the cleanest approach would be to simply read graphql queries from stdin, send them to client, and print result to stdout. Then various flags to configure various aspects of this

languid carbon
#

Would that include jq-style filtering, or rely on the user to handle the output as they wish

sly musk
#

one or the other

#

I kind of like having basic filtering included, that seems helpful to me

#

but probably we'd have to draw a line where we don't try to reinvent all jq

#

@languid carbon can you remind me where you bash demo is? sorry

#

want to illustrate with that

languid carbon
#

yeah I think I know what you mean. like if I pass

query Workdir {
  host {
    workdir {
      read {
        id
      }
    }
  }
}

to graphql, I'd love to just have the id itself as stdout. But for more complicated queries it might not be as easy to deduce what the output should be

sly musk
#

right, that stuff

#

For now I'm keeping it out of scope though. Assume either way it can be decided as an add-on

#

What's the name of that command-line tool by Hasura that lets you interactively type requests?

languid carbon
#

I haven't used it actually, but is it similar to the node or rails interactive experience?

sly musk
#

It's pure graphql

#

but you write it in stdin like a shell. And in an interactive terminal, it includes auto-complete

#

That's the inspiration basically

languid carbon
#

Ohh interesting. I'll try it out!

sly musk
#

Also things like: gq <endpoint> --introspect --format json > schema.json

languid carbon
#

That's pretty cool. Kind of a playground experience in the terminal

sly musk
#

Right, of course we wouldn't have autocomplete on the first version but we could add it later. It remains shell script friendly

#

And it can support a separate gql file

#

(I wonder if graphqurl supports that)

#

yup it does!

#

gq --queryFile queries.graphql --operationName Workdir

#

Makes me wonder if we should just fork gq 😄

languid carbon
#

What would prevent someone from using that directly against the engine?

#

lol or fork

sly musk
#

(Add that to the list of benefits: we could potentially write client in a different language than engine)

languid carbon
#

🦀

sly musk
#

0.3 CLI, all-in-one VS client only

#

CLI, all-in-one VS client only

#

CLI, all-in-one or client only?

sly musk
#

Basically "option 2" drastrically reduces the scope of the dagger CLI, down to a client only (gateway feature is included for SDK to wrap). Meanwhile the Engine is distributed as an OCI image only, leaving us free to split it up into various CLI tools as needed.

#

My feeling is that this could both make the UX simpler for users, and packaging easier for us

void bear
#

I am seriously enjoying the discussion in that issue. I will think about this for a few hours before I reply. Thank you to everyone that contributed!

sly musk
#

@crude apex @limber spear @dense flickeruzzardi can I pick you brains on the binary bundling problem this afternoon? Trying to get all the facts on the table before Erik goes on vacation... I promise to keep it short 🙂

crude apex
limber spear
#

will be good to go in a few mins, I'll be be away from ~2:45PST onward though

sly musk
#

2pm ok?

#

thanks 🙂

sly musk
#

Update: I spoke to Alex & Erik. Then later to Sam & Andrea. We have a tentative solution that minimizes disruption for next week, and gradually gets us where we want to be. I will write up a summary by monday. I think everyone will like it 🙂

Have a great weekend everyone