Is this part correct? `if errors.As(err

[reef kindle]

No I think right now you'd need to do this check:

if status.Code(err) == codes.NotFound {

since it's coming from the grpc session attachable

(Also I think you need that regardless of whether you go with the suggestion I had)

[versed arrow]

@reef kindle thanks. Well in the current code I call exists which I think will return false if the file doesn't exist. So I don't think I need to do special error handling beyond that.

(At least I hope so because that's the only reason I call that exists in a separate select in the first place)

(separately, it looks like removing the offending error checking code doesn't fix my test failures, I'll keep digging)

Maybe I'm not as close to merge as I thought 😭

[reef kindle]

yeah, thinking about that more it might not work out like that actually 😕 The problem might be that the error is coming from the Host.directory call since it's a case where the parent directory itself doesn't even exist (nevermind the .env file)

[versed arrow]

Side note, it's hard to get a birds eye view of all the go tests that fail. Like a complete red/green grid

[versed arrow]

Ah right, that too

If you're ok with it, I'll just drop that particular optimization for now, not because I don't care about it, but just to try to get something merged before I lose my footing and nothing gets merged at all..

I already have a growing list of follow-ups

(eg. had to drop system variable lookup because Justin has a cache concern)

[reef kindle]

Yeah the optimization is not a blocker but I don't think this issue has to do with the optimization at all iiuc

[versed arrow]

can't pass the --env-file CLI flag because somehow it gets dropped in nested execs and never managed to figure out why

etc

[versed arrow]

right. There's something else that's causing lots of tests to fail, cause unknown

This one is super weird, seems so random

ie - what is it about a module ref with a @ in it, that fails in my PR, even though the test is unrelated to my PR

[reef kindle]

There's a lot of tests failing besides that one, this is what I see (from latest run)

It's the same issue as before: https://github.com/dagger/dagger/blob/141cb5a652926486a33d7cbb839d24d6f3649c32/core/modulesource.go#L291-L297

You are hitting the error on Host.directory because the parent dir doesn't exist during dagger init, so you need to check if status.Code(err) == codes.NotFound and consider that the same as "not exists"

which is a weird behavior, would obviously be better if the host directory load was even lazier and thus supported chaining a .exists in the way you want, but that's way outta scope

[versed arrow]

So it's the module directory itself that doesn't exist when my code is called via dagger init?

[reef kindle]

Yeah, at least in the test cases that are failing it's doing a dagger init on a dir that doesn't exist yet

not all the test cases are failing though since I think most of them just do dagger init on a dir that already exists (and is empty)

[versed arrow]

ok I see. It's just that that code of mine is called from pretty deep in ModuleSource schema, in places where I would expect the directory to already exist

[reef kindle]

yeah, it will get created on the host only at the very end when the new module source is exported back to the client

[versed arrow]

Specifically it's called via LoadUserDefaults, at the very end of localModuleSource, gitModuleSource, directoryAsModuleSource, moduleSourceWithSourceSubpath, moduleSourceWithName, moduleSourceWithSDK

Ok I totally missed that situation, where it doesn't exist yet and gets exported at the end

[reef kindle]

yeah, keeps the CLI as dumb as possible. No direct local mkdir's before the module source has been successfully created, etc. Just an export at the end of the chain to create the module source

[versed arrow]

testing now

Out of curiosity: when doing dagger init in this way, which entrypoint actually creates the ModuleSource? directoryAsModuleSource?

[reef kindle]

dagger init only works for local module sources, so it goes through localModuleSource

you can see the moduleSource call here: https://dagger.cloud/dagger/traces/98220d47fc38b22023dc6469414d5fa5?listen=0d17d0bce7e5b73a&span=46f5993e60987709

That one looks at the ref string, determines it's a local ref, and then branches: https://github.com/sipsma/dagger/blob/5e99c8fc2becce9e327f414291cfc04bcf4f4389/core/schema/modulesource.go#L268-L268

@versed arrow looks like it's all green, doing another quick review to double check but LGTM if no blockers

[versed arrow]

There's a flake no?