Replies: 4 comments 10 replies
-
Love the I see two paths for CUE:
Have we decided if we're going to take both paths or just the first? |
Beta Was this translation helpful? Give feedback.
-
There are a few users that I can think of who'd like a CUE SDK. One example is here- #3121 (comment) |
Beta Was this translation helpful? Give feedback.
-
Any preferences between |
Beta Was this translation helpful? Give feedback.
-
I don't know how much I can contribute but if there's anything I can do especially testing out new versions I would like to help as much as I can. I have a docker builder repo built on classic dagger. I'm definitely ok with reworking it to get on the latest dagger cue sdk. But I would like to figure out how to help this moved so I don't feel stranded while waiting. |
Beta Was this translation helpful? Give feedback.
-
Problem
We are developing Dagger SDKs for several languages, and rewriting the Dagger CLI to be a language-agnostic client, rather than a CUE-specific engine.
We intend to continue maintaining the original CLI (codenamed "dagger classic"), but we have not yet decided what to rename it to, and how to document and package it going forward.
Solution
I propose the following transition plan for dagger classic:
?
(see "choice of new CLI name" section) and make it part of the CUE SDKmain
branch, under the pathsdk/cue
(bikeshedding welcome)sdk/cue
directoryChoice of new CLI name
We have consensus on the following name:
dagger-cue
.We must choose a new name for the classic CLI. Proposed options so far:1.cue-pipeline
2.cue-dagger
3.dagger-cue
Please indicate your preference in the comments.Resources
A first draft of what docs for a CUE SDK might look like: #3431 (NOTE only structure changes, docs contents have not yet been edited to match the wording).
Feedback welcome!
Beta Was this translation helpful? Give feedback.
All reactions