Start Elixir SDK - #1
Open
wingyplus wants to merge 3 commits into
Open
Conversation
Port the Elixir SDK out of dagger/dagger:sdk/elixir into this standalone repo, on the CLI 1.0 SDK contract. Elixir has no built-in engine runtime, so this follows dagger/java-sdk: the repo owns both the SDK contract module and the runtime that new modules reference. - elixir-sdk.dang / mod.dang / template.dang implement the contract: initModule seeds only SDK-owned template files, targetRuntime points at github.com/dagger/elixir-sdk/runtime, and generateAll is the @generate hook. - Code generation moves from module load to `dagger generate`. mod.dang vendors the library plus schema-derived bindings into <module>/dagger_sdk, which is committed; runtime/main.dang becomes build-only and its codegen is a no-op. - runtime/main.dang guards on a missing dagger_sdk and points at `dagger generate` rather than failing on an unresolvable path dependency. - helpers/render-template reimplements the runtime's name conversions instead of using a general-purpose case library, which disagrees on acronyms and digits (strcase.ToCamel("HTTPServer") == "Httpserver", not "HttpServer"). A mismatch would name an Elixir module that does not exist at call time. - sdk/ holds the client library and dagger_codegen. Tests needing a live engine are tagged :integration and excluded by default, so `mix test` is hermetic. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Thanabodee Charoenpiriyakij <wingyminus@gmail.com>
A freshly scaffolded module has no committed dagger_sdk/ yet, but `dagger generate` must load every workspace module to discover generators before the SDK's @generate hook can write it. The runtime previously raised on the missing directory, and the resulting error spans crashed the release CLI's trace consumer, failing generate and every sdk-sdk check behind it. moduleRuntime now declares introspectionJson as required — the engine's opt-in to always receive the introspection schema, even for dagger-module.toml modules — and, when dagger_sdk/mix.exs is missing or empty, vendors the SDK and generates the API bindings on the fly before compiling. Committed sources remain the fast path and `dagger generate` still owns writing dagger_sdk/ to the workspace. The SDK sources reach the runtime's context through ../sdk include patterns in its dagger.json. Verified end-to-end against the engine at ac0edaa8: sdk install → module init → generate (exit 0, dagger_sdk written, fallback exercised at load) → `module engine required` prints v1.0.0-beta.10 → `api functions test-mod` succeeds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
Check all passed now |
wingyplus
commented
Aug 19, 2026
Contributor
Author
There was a problem hiding this comment.
Do I need to keep old changelogs?
Member
There was a problem hiding this comment.
No I think we don't care about changelogs.
/cc @eunomie @shykes @kpenfound for confirmation
Bumping sdk-sdk to 00bb067 picks up its own polyfill removal, and everything this SDK used `github.com/dagger/polyfill` for is now native in the engine. Module discovery is the biggest cut: `currentModule.asSDK(workspace:).modules` already applies the cwd policy the polyfill's `findConfigDirs` walk was reconstructing — modules at or below the cwd, plus the nearest enclosing one when the cwd is not itself registered — so the walk, the intersection against the managed list, and the cwd-to-root path mapping all go. Workspace staging goes through `withNewDirectory` / `withoutDirectory` / `changes(from:)`, and module sources through `Workspace.moduleSource`, which is the call the polyfill's `core` field was making. `workspaceView` and `sourceRootPath` become `contextDirectory` and `sourceRootSubpath`. The engineVersion bump to v1.0.0-beta.10 is load-bearing: that is the changeset cwd cutover, past which the engine measures a `Workspace.changes` result from the caller's cwd instead of the workspace root. That hands the re-rooting the polyfill used to do back to the engine — `dagger generate` from a subdirectory now lands its files in the right place — and it is why `generateAll` folds by workspace rather than by changeset: past the cutover each per-module changeset is measured from the cwd, which is not the frame `withChanges` applies them in. `Mod.generatedWorkspace` exists for that fold. Unlike the TypeScript SDK's equivalent change, `Mod` keeps its explicit `generateLocalDependencies` staging and its own `vendoredSdk` rather than delegating to `ModuleSource.generate(workspace:)`: Elixir's codegen lives in this module, so delegating would re-enter this SDK's own `@generate`. `initModule` carries any content already at the target path into the directory it stages. `Workspace.withNewDirectory` replaces its overlay entry rather than merging, so without this the changeset reports pre-existing files as removed, which `sdk-sdk:contract:does-not-remove-existing-files` rightly rejects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 96773de)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR makes the elixir-sdk compatible with Dagger pre-1.0. The SDK passes all sdk-sdk tests (run on my local machine) and is self-contained.