[WIP] Make Dagger Simpler

[shykes]

Overview

Dagger is too complicated to use. All the ingredients are there for a game-changing user experience, but it is buried in layers of incremental trial and error.

This proposal describes an leaner version of the dagger CLI, with the same core features but packaged in a different UI and API.

Objectives

The desired results are:

1. a simpler design: less code, less concepts, etc.
2. a streamlined user experience: more consistency between the different parts; remove cruft and legacy accumulated along the way.
3. a familiar experience for devops / SRE people, compared to their favorite tools.

Relationship to other proposals

This proposal is standalone, but incorporates elements from (and therefore conflicts with) these other proposals:

• One simple config file #793
• Environment schema #966
• Simplify inputs and outputs #970

Proposal

This is a baseline proposal. Omissions and disagreements are an opportunity to find the final design together.

WORK IN PROGRESS

Concepts:

• Environment
• Context
• Secret
• Artifact

Principles:

1. Embrace the Cue way
2. It’s OK to have a schema
3. Just edit the damn config file
4. Don’t try to own secrets
5. A git repo always has a home
6. Local dev is a killer feature
7. Avoid state at all cost

[grouville]

@shykes, very interesting ! Can you please detail the principles 5 and 7 ? Even though I get the idea, not sure to entirely understand the reason why they're principles (their implications, etc)

[shykes]

@shykes, very interesting ! Can you please detail the principles 5 and 7 ? Even though I get the idea, not sure to entirely understand the reason why they're principles (their implications, etc)

I will add more details on all points, just wanted to write down the structure so I don’t forget it :)

5: this is related to an ongoing challenge for Dagger: mixing content from inside git (cue configurations) and outside git (state, secrets, runtime information etc). We have tried many different approaches and so far none of them feel great. The current approach is to store everything inside git, with .gitignore files for information that should not be committed. It works so far but only for use by a single user on a single local machine with an interactive UI. We don’t know yet how to make it work across multiple users, multiple machines, and non-interactive environments (eg. your CI). One thing we have not tried is rely on git remotes as a namespace. In theory a local git repo isn’t guaranteed to have a valid remote; but in practice we can safely assume they will. If we make that assumption that “every git repo has a home” (the home being the remote), then it becomes possible to move some information out of the repo (for example in a home directory) while still connecting it back to local repositories in a way that is robust. For example if you move your local git repo to a new location on your machine, the remote will remain the same… So dagger can detect correctly the git context and find corresponding state, secrets, runtime information. This means we no longer have to store everything in the user’s repo even when it’s awkward.

7: this is a general principle of computer science that managing state is hard, and the less state your software is responsible for, the better. This applies to Dagger as well.

[aluzzardi]

@shykes Is this addressed by Europa or other issues (e.g. ok to close)?

[shykes]

Yes ok to close, thanks. The quest to make Dagger simpler will continue… forever 😀