Windows support need to be explicitly supported. Right now we neither test on windows, or develop on it (I don't at least). As such this issue tracks the progress of both:

• Windows CI
• Windows Support

Hey, love this! Thanks for supplying it.

Perhaps I am going about this wrong, but take the following example:

#![feature(async_closure)]

use dagger_sdk::{ContainerBuildOptsBuilder, HostDirectoryOpts, QueryContainerOptsBuilder};

static DOCKER_FILES: [&str; 3] = ["Dockerfile", "Dockerfile.alpine", "Dockerfile.distroless"];
static PLATFORMS: [&str; 2] = ["linux/arm64", "linux/x86_64"];

#[tokio::main]
async fn main() -> eyre::Result<()> {
    let client = dagger_sdk::connect().await?;

    let context = client.host().directory_opts(
        ".",
        HostDirectoryOpts {
            exclude: Some(vec!["target", "client/node_modules", "client/build"]),
            include: None,
        },
    );

    for file in DOCKER_FILES {
        for platform in PLATFORMS {
            let ref_ = client
                .container_opts(
                    QueryContainerOptsBuilder::default()
                        .platform(platform)
                        .build()
                        .unwrap(),
                )
                .build_opts(
                    context.id().await?,
                    ContainerBuildOptsBuilder::default()
                        .dockerfile(file)
                        .build()
                        .unwrap(),
                )
                .export("./test")
                .await?;

            println!("published image to: {:#?}", ref_);
        }
    }

    Ok(())
}

How do I actually put the platform in? Currently it errors with:

error[E0277]: the trait bound `Platform: From<&str>` is not satisfied
    --> ci/main.rs:25:35
     |
25   |                         .platform(platform)
     |                          -------- ^^^^^^^^ the trait `From<&str>` is not implemented for `Platform`
     |                          |
     |                          required by a bound introduced by this call
     |
     = note: required for `&str` to implement `Into<Platform>`
note: required by a bound in `QueryContainerOptsBuilder::platform`

But I also can't put the Platform in there as:

error[E0423]: cannot initialize a tuple struct which contains private fields
  --> ci/main.rs:27:35
   |
27 |                         .platform(Platform(platform))
   |                                   ^^^^^^^^ help: a local variable with a similar name exists: `platform`
   |
note: constructor is not visible here due to private fields
  --> /home/pyxxil/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dagger-sdk-0.2.16/src/gen.rs:18:21
   |
18 | pub struct Platform(String);
   |                     ^^^^^^ private field

Any help would be great! Cheers

Currently we don't test on MacOS (aarch and amd64).

I develop on this platform and run both amd64 (via. dagger) and aarch natively, as such this can be considered to be tested. However, we need it enabled for CI as well

This can be fixed by manually downloading the dagger engine. Or downgrading.

I will fix this tomorrow

genco/rust requires nightly for whitespace detection, there is a way around it, I just need to do it manually.

This is just a small issue to keep track of it, so I don't forget to move it to stable.

Currently only agent architectures are supported. The blocker here is that qemu doesn't allow file actions as such integration tests can't be run on other architectures or platforms. To solve this issue, we need to run tests in a docker container under qemu.

Right now the codegen code is heavily inspired by the upstream python dagger sdk. There is a however a much cleaner way to parse the code. Mainly relying on enums and traits to perform predicates and such.

This would involve splitting the codegen part into a lexer and so on, to first transform it into an internal representation of the graphql, which in turn is then turned to generated code using traits etc.

This however, should wait until the API is somewhat stable to not have unnecessary refactoring.

Evidence: github.comm/kjuulh/dag

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Other Branches

These updates are pending. To force PRs open, click the checkbox below.

• fix(deps): update all dependencies (async-trait, base64, clap, dirs, docker/setup-buildx-action, flate2, genco, graphql_client, hex-literal, itertools, platform-info, reqwest, serde, serde_json, sha2, tempfile, tokio, tracing-subscriber)

Detected dependencies

Hey, thanks for the quick fix with #30!

I've ran into another issue while trying to expose a port (with a protocol included).

Code:

client.from("denoland/deno:debian-1.30.3")
    .with_exposed_port_opts(
        53,
        ContainerWithExposedPortOpts {
            protocol: Some(NetworkProtocol::TCP),
            description: None,
        },
    )
    .with_exposed_port_opts(
        53,
        ContainerWithExposedPortOpts {
            protocol: Some(NetworkProtocol::UDP),
            description: None,
        },
    )
    .export("/");

Results in the following error:

GQLClient Error: Look at json field for more details
Message: Argument "protocol" has invalid value "TCP".
Expected type "NetworkProtocol", found "TCP".
Message: Argument "protocol" has invalid value "UDP".
Expected type "NetworkProtocol", found "UDP".

Also yank the dagger-rs crate

I have the following in my .cache/dagger:

tree ~/.cache/dagger/
~/.cache/dagger/
├── dagger-0.4.2
├── dagger-0.5.0
└── oci
    └── ingest

Running the examples fails on

Error: Is a directory (os error 21)

Removing the section that calls std::fs::remove_file fixes the problem. Not sure why deleting the other files would be necessary.

The idea behind this is to support what the other sdks do with id().

I.e.

directory := client.Host().Directory(...)

client.From().Container().WithDirectory("/", directory)

vs

let directory = client.host().directory(...)

client.from().container().with_directory("/", directory.id().await?)

This is quite a bit more verbose, and not as efficient.

All the sdks does this differently, for dynamic languages a directory is transmuted into a directoryId on read time when a final execution is called .exit_code etc. Or in golang, where an interface is implemented to tell the serializer that it contains an ID, and that it should be called, when an arg is tried to be serialized. Such that a directory (struct) as an arg is serialized as id (string).

The benefit of this process is that the intermediary steps aren't executed eagerly. Right now .file() or .directory() are executed when passed to another function, instead of when .exit_code() or equivalent is called.

There are a few blockers for fixing this:

• Serialization should be moved to execution, this means somehow storing the raw arg, this can be tricky as Rust is not very happy about dynamic types, in go the raw pointer (interface{}) is stored, this is mostly not an option in rust, it can be done, and is potentially our only option. Another option is storing a closure, this preserves input information, but again, rust really, really is janky when storing special expressions like lambdas.
• Non-standard serialization: Enums are handled differently in graphql, than json, (they are explicit values TYPE instead of "type", i.e. graphql wants non string wrapped types, while json always wants strings wrapped. It isn't possible override serdes implementation here, so instead I've opted to just remove the quotes from the string manually before passing them to the requester. Again, this may be solved using a closure, or embedding extra information in the arg, or implementing an entirely custom serializer, like what is done in go.

This will probably be fixed in a single change. I am probably gonna do some experiments to see what the easiest solution will be.

The specifics are this:

should be moved to this:

When dropping the connection check if there are existing pipelines not handled, if so throw an error

This is about testing all standard apis via. gen.rs in dagger-sdk.

The goal is to produce tests for each individual feature.

I am gonna work on this over the next few weeks, but is someone wants to pitch in, feel free to reach out.

Currently dagger-run is not supported as the sdk cannot rely on an existing
connection and will try to replace the existing dagger engine