Justin Chadwell

I'm suggesting leave it under `engine`, but go back to duplicating the information in `runtime` folders (with comments though).

I think this should still be a separate function. We now have various `InitOpts` (e.g. this is how `embed` is propagated around). We should pass these through an `Initialize` function,...

Rebased, and chucked some huge simplifications to the go mod update and such in. Not quite sure the final form of this, so keeping in draft, and discussing with @helderco...

I significantly prefer this option to trying to mix dagger code into the project root in an SDK-specific way (like `internal/dagger`). For one, this option as suggested is actually *relatively*...

Relevant user comment: https://github.com/dagger/dagger/pull/7864#issuecomment-2283607492 > For reference, I did this (and I've been doing ci/cd for a while): > > - Came to dagger.io and perused the docs (guilty for...

Mmm, the comment above kind of convinces me that we should at least *try* the switching behavior based on the contents of the target directory. I still think it's confusing...

Hm, this is tricky. cc @vito :tada: I'm not *necessarily* convinced that we should propagate a SIGINT through to services being run - the processes are being run remotely, etc....

Linking this to https://github.com/dagger/dagger/issues/6493, since there's continued discussion of service stop semantics there as well.

Aha, this is a more specific version of https://github.com/dagger/dagger/issues/8584. Note that this is fiddly to reproduce because the buildkit internal git state can get into a very weird inconsistent state.

As suggested by @sipsma in https://github.com/dagger/dagger/pull/8574#issuecomment-2375505502, I think this is potentially caused by the caching socket issue, very similar to what I described around secrets in https://github.com/dagger/dagger/pull/8358#issuecomment-2346006330 (though the solution...