Erik Sipsma

@vito @aluzzardi I got hard blocked by a need for bootstrapping in this PR: https://github.com/dagger/dagger/pull/3983 So I went ahead and rebased this and applied the simplifications discussed in comments: 1....

Okay after writing my last comment I went back to use this on #3983 and realized there was *still* a catch 22. Fortunately I found a fix that's relatively painless...

@vito thanks for the rebase, was just about to do that and saw it was already done :-) @aluzzardi let me know if you have any concerns with this approach

> As in, we put a go.mod in internal/mage and the pipelines are always targeting a stable release. Whereas our tests always target main (root go.mod has a replace) That's...

> I would have assumed that mage uses stable (sdk and engine) all the way up until exec(go test) (and mounting the dev session binary), at which point we'd "switch"...

> The only problem though is it would be talking to "stable" engine, assuming the shim sets up _EXPERIMENTAL_DAGGER_RUNNER_HOST Yeah exactly, we wouldn't actually be testing the engine we want...

(I just saw that the merge commit from before seems to have undone some new logic in the nodejs publish step, fixing, then will merge once I have an approval)...

I used the squash and merge button based on recent advice, for some reason that resulted in `undefined` being the commit message? https://github.com/dagger/dagger/commit/58c782e6d5de4992046f2b1ebeea52948ae793fd Sorry that looks weird @vito, I didn't...

> Did you mean to set XDG_CACHE_HOME to it? Yes! Thank you for noticing that and for the other cleanup commit @helderco ! I rebased, it should be good to...

We continued this thread here: https://github.com/dagger/dagger/issues/3830