#dagger checks/foo
potent sorrel
What do you imagine it would look like if you wanted to query multiple checks? dagger checks/foo checks/bar?
hollow monolith
Hadn't thought about it, that also raises the question of something like dagger checks/foo artifacts/bar
tardy wharf
I think that would make more sense in the context of a special dagger query
at which point my reaction is “might as well write graphql”?
unless the slash notation is meaningfully simpler to learn than graphql in which case I can see it. but would have to map closely to underlying graphql so that it’s a learning stepping stone
hollow monolith
it's definitely not meant to be a building block for mid-level complexity queries or anything like that
just trying to improve on the awkwardness of dagger checks foo and drive home that you're querying something
dagger checks foo could be misconstrued as "run the foo subcommand of the checks namespace" for example, and also prevents us from being able to have subcommands at all (if we want that)
just a fleeting thought tho!
fathom zinc
"dagger checks foo" reads like a verb 😛 "<subject> <verb> <object>" (e.g, erik checks the news).
In REST you have this structure as well: /users/<uid>.
fathom zinc
This is starting to feel like this image. If you wrap your mind that "checks" is "the thing", then dagger checks foo isn't awkward at all. Not sure what we can do from the CLI arg structure to make that clear on its own. In the same mindset, dagger tests unit also fits, when it's already clear that dagger <collection> <thing>. But is there a delimiter (like /) that makes this relationship clearer? Or we just depend on documentation (--help)?
hollow monolith
"dagger checks foo" reads like a verb 😛 "<subject> <verb> <object>" (e.g, erik ...
to some people it reads like a verb, sure, but in many CLIs it can just be a command namespace, especially when it's plural: https://developer.hashicorp.com/vault/docs/commands/secrets/enable
honestly there's no consistency across CLIs here, we just need to be internally consistent, and to evoke the right mental model
imo the most impactful question is whether we'll ever want sub-commands for these things (whether for the whole collection like checks or individual items like checks/foo), because that determines what syntax we can even use
fathom zinc
In REST you have this structure as well: `/users/<uid>`.
In rest it's actually: <verb> <[collection]:resource>: GET /users/uid, UPDATE /users/uid.
I don't see myself not needing subcommands.
For checks, without side effects, that's mostly for performance. I don't want to run the entire test suite for all sdks when I'm working on a single test file.
For subcommands, how do we want to think about our own CI? Each SDK a separate environment with a flat list of commands? Because that's all you can do if you don't support subcommands.
hollow monolith
For checks, without side effects, that's mostly for performance. I don't want to...
yeah definitely. but by sub-commands I mean things besides 'run only this check'; I mean theoretical things like dagger checks/foo rerun or dagger checks/foo history or dagger checks/foo inspect.
fathom zinc
Oh, I see.
hollow monolith
i.e. operations you can run against checks, which might traditionally be structured like dagger checks inspect foo or something
if our way to run individual checks is dagger checks foo that kind of paints us into a corner
fathom zinc
The actual verb: dagger checks [action (default GET)] <resource>
hollow monolith
yeah, that seems like a pretty consistent model with the rest of the world. the "default GET" is the only tricky part due to ambiguity
fathom zinc
Yep
hollow monolith
i think at one point my CLI mockup had checks get <foo> and then check was just an alias for checks get
fathom zinc
Yeah. get actually makes it pretty clear you're querying data.
GitHub uses singular (issue, pr, release, repo...).
gh issue - Manage issues
gh issue list
gh issue view 123
1Password also uses singular:
op user list
op user get <user>
Fly uses plural (but has singular as alias):
fly apps list
fly apps destroy <app>
hollow monolith
Having both plural + singular alias to the same thing makes sense to me. I think it comes down to how often you're operating against individual (get) vs collection (list), which might change from type to type. Also some CLIs have single-letter aliases, which completely dodge the singular vs plural question.