#getting a codegen error using `Optional`
1 messages · Page 1 of 1 (latest)
error here:
exec /usr/local/bin/codegen --module . --propagate-logs=true ERROR [0.76s]
┃ Error: generate code: template: module:56:3: executing "module" at <ModuleMainSrc>: error calling ModuleMainSrc: failed to convert method Build to function def: failed to convert param type: invalid type: inval
┃ type
┃ Usage:
┃ codegen [flags]
┃
┃ Flags:
┃ -h, --help help for codegen ┃ --lang string language to generate (default "go")
┃ --module string module to load and codegen dependency code
┃ -o, --output string output directory (default ".")
┃ --propagate-logs propagate logs directly to progrock.sock
┃ Error: generate code: template: module:56:3: executing "module" at <ModuleMainSrc>: error calling ModuleMainSrc: failed to convert method Build to function def: failed to convert param type: invalid type: inval
┃ type
This is trying to update @grizzled quiver 's hugo module in this fork: https://github.com/kpenfound/jedevc-daggerverse/blob/update_hugo_0.9.x/hugo/main.go#L15
weiiiird - using your code, i also get codegen issues, but i get:
✘ asModule(sourceSubpath: ".") ERROR [2.26s]
✘ exec go build -o /runtime . ERROR [0.64s]
┃ # hugo
┃ ./main.go:32:54: undefined: dartVersion
┃ ./main.go:32:72: undefined: DEFUALT_DART_VERSION
┃ ./main.go:46:27: undefined: opt
┃ ./main.go:47:27: undefined: opt
┃ ./main.go:51:10: undefined: runtime
┃ ./main.go:64:10: undefined: runtime
• Engine: 88a9b4c1f423 (version devel ())
⧗ 2.64s ✔ 16 ∅ 2 ✘ 2
Error: failed to automate vcs: failed to get vcs ignored paths: input:1: host.directory.asModule failed to call module "hugo" to get functions: failed to get function output directory: process "go build -o /runtime ." did not complete successfully: exit code: 1
@rough cobalt have some fixes 🎉 https://github.com/jedevc/daggerverse/commit/ed906441733ac0a958198f6d5e4a0de61ab667df
is it from your old dagger.gen.go?
no idea why you get that insane error
it seems to come from: https://github.com/dagger/dagger/blob/9eba91a52e956b26d3c8db90bc2ed60b30abf88c/cmd/codegen/generator/go/templates/modules.go#L496-L498
this indicates some incredibly broken type, i'm not quite sure where it's from
I'm at least as confused as you are about that lol. Btw this is on dagger@9eba91a
which is that commit
yeah same 😢
did the code in my fork look roughly how you'd expect the Optional stuff to look?
yeah i can actually generate the code perfectly off of this
thought, could this be some weird caching issue? i know there's something weird where the codegen won't update if the source file doesn't update
(even though the engine updates)
could be, let me pull those changes to my fork and see what it says
I guess it could be my gitignored dagger.gen.go
it's unlikely to be that i think - i don't think the dagger.gen.go is loaded during codegen, we always regenerate a new one server-side in the engine
removing the dagger.gen.go made it pass 😭
Only briefly skimmed this so far (neck deep in fixing other stuff), but the caching problem is related to the fact that the engine version doesn't end up in cache keys, which creates very confusing behavior when using non-official released engines. Planning on fixing that next: https://linear.app/dagger/issue/DEV-2852/invalidate-module-load-cache-if-engine-version-changes
In the mean time, if you are using a dev engine, docker rm -fv dagger-engine.dev; docker volume rm dagger-engine.dev will clear the whole cache
removing the dagger.gen.go made it pass 😭
It may be that removing it nudged the cache key and got rid of the problem in a different way
i don't think the dagger.gen.go is loaded during codegen
It is still loaded, though loading it isn't really necessary, we just didn't add an explicit exclude yet
i need to headoff now - but @rough cobalt if you can push wherever you get to with the hugo module stuff, i'll happily follow-up with it
i also have a branch https://github.com/jedevc/daggerverse/tree/github-versioning which i'm planning on merging at some point that gets the latest release assets from github (but also, lol i'm hitting more issues with v0.9 that need fixing 😢)
i wonder if something with parsing dagger.gen.go as well causes a weird package parse error and we get an invalid type? something like a duplicate declaration or a type doesn't exist?
Awesome thanks for the assist! I'll make a PR with my changes since I can work off my fork tonight
We've definitely gotten into a weird spot with the dagger.gen.go state a few times @viral steppe
It's possible actually, the thing I'm neck deep in is fixing https://linear.app/dagger/issue/DEV-2793/zenith-dagger-mod-use-causes-a-rollback-on-code-compilation-failure, which has ended up revealing some pretty deep issues in the codegen/runtime part of things. Fortunately I finally understand what's going on and am fixing now. It may end up fixing other related problems too (things were just barely working due to a series of coincidences previously)
awesome, awesome 🎉
with DEV-2793, and DEV-2852 and maybe an exclude of dagger.gen.go for good measure, hopefully we shouldn't end up in odd states like this again
@rough cobalt you don't have your old dagger.gen.go that you deleted around anywhere? something that we could test with to see if this gets resolved by what @gloomy marten's working on 
No, but I could probably retrace my steps if it's helpful
I'm gonna add more integ test coverage that try to model more "real world" usage (i.e. creating modules, running them, then changing them and running again, etc.). So I may end up hitting this there anyways, so not worth a ton of effort on your end (but if it's trivial then sure, I can turn it into a test case 🙂 )
@rough cobalt I've merge github-versioning and your update_hugo_0.9.x branch into https://github.com/jedevc/daggerverse's main
just a note - i found another graphql issue which is resolved by https://github.com/dagger/dagger/pull/5966, so it needs a build off of that to use the hugo module
but aside from that... it works 🎉
Nice thanks! I added an optional for environment as well since I'm using that flag in my demo
i grabbed that as well i think 🎉 https://github.com/jedevc/daggerverse/blob/main/hugo/main.go#L18
just discovered - my prior statement is untrue apparently
https://github.com/dagger/dagger/blob/ed98d775ad923c56f130bbf5237fda0399fde1b4/cmd/codegen/generator/go/generator.go#L65-L78
we don't always regenerate from scratch, it looks we use whatever we provided as the user there 
i wonder if that's where the weird bug came from
😢 looks like this isn't that hard to hit: #daggernauts message
I'm just going to make a quick change to remove that file before calling go codegen. It is in the vcs ignore paths, but still gets loaded from the local/git source in the first place, and clearly seems to be throwing a wrench into something.
SGTM - I think it probably deserves a more thorough investigation at some point (happy to volunteer for that), but that'll have to wait for a bit 😔
Yeah totally agree, just want to alleviate short term pain in meantime
We can just leave another // TODO 😩