#With `nc -l 4242` running in another

1 messages ยท Page 1 of 1 (latest)

calm quarry
#

Trying, we have integ test coverage for this so it should work but maybe some weird case is getting hit

lean dagger
#

Hard to tell what service the error is talking about - mine or the target

calm quarry
#

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.

lean dagger
#

It's a host service, so weird that I can "start" it

calm quarry
lean dagger
#

(went on a quick detour to re-publish my tailscale module, apparently it got wiped at some point, possibly because of missing license.)

calm quarry
#

I'm gonna make the change to auto start either way. It's a one-line fix

lean dagger
#

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)

shrewd ravine
#

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

calm quarry
#

Yeah I'm guessing it doesn't notice the dag var in dagger.gen.go and thinks it must be an import ๐Ÿ˜ตโ€๐Ÿ’ซ

shrewd ravine
#

i'd expect it to work if you dagger mod sync and restart the editor

lean dagger
#

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.

calm quarry
#

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

lean dagger
#

Ah!

#

I think develop might still work, linting is still part of the dev process? Maybe?

calm quarry
lean dagger
#

Yeah

#

My issue with codegen is that it's not obvious why you would run it (or when)

lean dagger
#

I guess if we can answer that question clearly, it might help us pick a name ๐Ÿ™‚

lean dagger
#

Thanks

#

Adding explicit start...

#

Ok it worked ๐Ÿ™‚

calm quarry
#

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

calm quarry
#

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

GitHub

Before this, services provided as CLI flag values were not automatically started, so user module code needed to explicitly start them (or implicitly start them via a service binding), which is some...

lean dagger
#

Not even a little bikeshedding, I want my money back