#Is there a good recommended workflow for
1 messages Β· Page 1 of 1 (latest)
Also abit awkward if I want to iterate on a daggerverse module that's already pushed ...
"dependencies": [
{
"name": "golangcilint",
"source": "github.com/papercomputeco/daggerverse/golangcilint@main",
"pin": "8646f8127d0bb464437e12f0a5d83d72edc211d8"
}
],
would be amazing if there was a dagger install override command that could provision an override locally in something like dagger.override.json. Maybe something like:
{
overrides: [
{
source: github.com/papercomputeco/daggerverse/golangcilint@main,
replace: ../daggerverse/golangcilint
}
]
}
then I could also add that override to gitignore and keep remote clean.
Agree its a bit awkward. A replace would be cool but at the moment it can't escape the git context.
One thing I do for modules that really need testing is use the example to exercise the happy paths https://github.com/kpenfound/dag/blob/main/artifactory/examples/go/main.go
These also get rendered in daggerverse as long as they're named correctly
Hmm gotcha! Consider me an advocate for a dependency override feature or absolute path resolution in deps! I've generally left out examples and tests in my daggerverse modules since it ends up being alot of Go boilerplate. For example, this one I'll likely hoist out but probably isn't worth its own example/test harness:
https://github.com/papercomputeco/tapes/blob/main/.dagger/tidy.go
Hit some nasty snags that may have been easily caught with a nice local dev flow:
β― dagger call --help
β connect 0.5s
β load module: . 0.7s ERROR
β loading type definitions 0.1s ERROR
! main object not found, check that your module's name and main object match
I had already pushed this up and was getting an all green build on dagger install and dagger develop ... but the module wasn't there! Would be very ideal if dagger install failed if the module was invalid!
upcoming workspaces seem like the perfect place to configure replace directives... π #1468070450524459029
Hi π
Taking a go today about it, thanks for the feedback πΌ
Ooo modules v2 π yβallβs cookin
If I understand correctly, dagger install silently installed a module that fails to load? I find that surprising! But maybe it's a regression we introduced when we made module loading lazy