✔️ Deploy Preview for devel-docs-dagger-io ready!

🔨 Explore the source changes: da90baa

🔍 Inspect the deploy log: https://app.netlify.com/sites/devel-docs-dagger-io/deploys/62264b476f7eae0007f347b6

😎 Browse the preview: https://deploy-preview-1668--devel-docs-dagger-io.netlify.app

For context/history purposes: tested locally with @helderco

The npipe implementation works, but there are still two parsing issues when retrieving the absolute path (in Windows only). Also, Cue makes it impossible, in the current form, to specify powershell paths: \\.\pipe\docker_engine

Thanks @grouville, can you please test again, just to confirm?

dagger.exe -p ./tests/plan/client/filesystem/read/service/windows.cue do test

Also, Cue makes it impossible, in the current form, to specify powershell paths: \\.\pipe\docker_engine

Yeah, you'd need to escape all of those back slashes, but it's possible:

filesystem: "\\\\.\\pipe\\docker_engine": read

@aluzzardi Should I maybe do the cleanup in another PR instead of this one?

Thanks @grouville, can you please test again, just to confirm?

dagger.exe -p ./tests/plan/client/filesystem/read/service/windows.cue do test

Tested locally. Everything works fine, even with "\\\\.\\pipe\\docker_engine". LGTM on this part 🔥

Before this change, we would use inputs.params.app.name

This property used to help distinguish between cache mounts, e.g. https://github.com/dagger/dagger/pull/1693/files#diff-d941b232905b7945682101f64df497593dcb84a5c987bd59e46fb54bd5cd3117R33-R38

How does this change affect that approach?

The answer to that depends mostly on #1648.

You can just move params into actions:

dagger.#Plan & {
    actions: {
        params: app: *"todoapp" | string

        build: {}
        test: {}
    }
}

It doesn't have to be params. --with overlays with any field, no matter the name/structure.

More context:

Where would you keep inputs: params and outputs: values?

Good question. They are out of scope from client, but there are hints of possible solutions:

• human-readable outputs: Action API #1598 defines a $dagger: after: string field to control what is printed to the user

• machine-readable inputs & outputs: 0.2 CLI #1558 defines a new UI where the focus is on a single action. Since actions have fields already.. maybe those can act as params/values and there is no need to duplicate? More design & discussion needed.

Originally posted by @shykes in #1597 (comment)