#With `nc -l 4242` running in another
1 messages ยท Page 1 of 1 (latest)
Trying, we have integ test coverage for this so it should work but maybe some weird case is getting hit
Hard to tell what service the error is talking about - mine or the target
Oh interesting, in our integ test we take the service argument and use it as a service binding (https://github.com/sipsma/dagger/blob/ce44608a87b72152b1d4c1b2d042417299d2188d/core/integration/module_call_test.go#L34-L34).
So I think it's getting automatically started there. But in your tailscale module you are using it directly. Which makes sense but may explain this. Does it work if you add a line below here like backendService = backendService.Start() https://github.com/shykes/daggerverse/blob/main/tailscale/main.go#L22
If so, I guess we probably should just start it automatically from the CLI so that can be skipped in any consuming code. Can't think of any case where you wouldn't want it started for you.
It's a host service, so weird that I can "start" it
Right, that's just how the service API works, but agree in this case it looks weird.
(went on a quick detour to re-publish my tailscale module, apparently it got wiped at some point, possibly because of missing license.)
I'm gonna make the change to auto start either way. It's a one-line fix
New detour: my IDE auto-adds this import on save: "dagger.io/dagger/dag"
Literally can't get VS Code to not add it
(in my tailscale module)
goimports giveth, and goimports taketh; i'm still trying to teach it to ignore golang.org/x/exp/slog ๐ญ
dagger.io/dagger/dag is the new global client i think
oh, and maybe you don't have a local dagger.gen.go so it doesn't know dag is a magically generated var
Yeah I'm guessing it doesn't notice the dag var in dagger.gen.go and thinks it must be an import ๐ตโ๐ซ
i'd expect it to work if you dagger mod sync and restart the editor
will try that
btw: how do you feel about renaming dagger mod sync to dagger mod develop?
Would remove confusion with "file sync" and "Sync(ctx)". I've already seen someone be confused by those two. Can't hurt to remove a third use of the same word from the equation.
Agree sync is probably not best, but I don't know about develop since we've in practice been finding that more often than not we actually need to commit the generated files so that CI can lint module source code, which makes it needed beyond develop-ment time. Maybe dagger mod codegen.
Which reminds me that as yet another tangent, once current tasks are done I was gonna send out a PR to remove the .gitignore we currently setup by default, for the reasons above
Ah!
I think develop might still work, linting is still part of the dev process? Maybe?
I guess develop makes me think "only needed locally on my development machine". But highly subjective of course, just my immediate impression
Yeah that's true too
I guess if we can answer that question clearly, it might help us pick a name ๐
Running dagger mod sync worked
Thanks
Adding explicit start...
Ok it worked ๐
For some reason the "simple" fix to call start in the CLI is not actually fixing it in the integ test I added (still says its not started), so need to look a little bit more at why, but either way should be fixable so you don't need to include the Start in your code
Okay got it working but it required a subtle-yet-meaningful change to how services are shared across a session (key their state by the shared server id rather than by each individual client id), so would like your input @shrewd ravine when you have a min: https://github.com/dagger/dagger/pull/6425
approved
Not even a little bikeshedding, I want my money back