Erik Sipsma

I'm not sure what the linting error is, all I see it saying is: ``` #21 poe lint #21 0.224 Poe => flake8 . Error: input:1: container.from.exec.withEnvVariable.withEnvVariable.withEnvVariable.withEnvVariable.exec.exec.withEnvVariable.withEnvVariable.withEnvVariable.withMountedDirectory.withWorkdir.exec.exec.exitCode process "/_shim poe...

> Given the speed of this repo -- should we merge this even if unfinished to avoid rotting? Or are there side effects to the non-wasm codepath? I think I...

This issue is coming to a greater head w/ the engine image and local binaries. We need to explicitly choose whether or not we want to package helper windows binaries...

> I think we should. It makes sense at least on paper. I can't speak to difficulties of testing & packaging, which may lead to implementation tradeoffs. I'm going to...

@aluzzardi > Totally missed this PR No worries, I rushed out something for a user who wanted it on short notice and was okay with a separate branch. None of...

@dolanor Our goal is to get [dagger.json in for the preview](https://github.com/dagger/dagger/pull/3281), so I'd prefer we merge that before this one, but I think that your PR here still makes sense...

> My main concern is our tests go through 3 different DAGGER_HOST -- 1) bootstrap with release engine 2) run pipeline with bootstrapped engine 3) dagger-in-dagger for tests running in...

Agree, the name `examples` is leftover from ancient times. We could also just move the extensions to be under `core/integration/testdata` for now since there's some tests for them in there...

@jlongtine how absurd and awful of an idea is this: you currently can load secrets from env vars, so whenever you need to load a secret in dagger-cue you export...

cc @shykes @aluzzardi cc @helderco summary of the discussion around all this and reasons why we're currently pursuing the option in https://github.com/dagger/dagger/pull/3647 (though any and all feedback is still welcome,...