#`telemetry.Tracer(ctx).Start(ctx, "foo")
raven matrix
@fierce sand it worked! But super buried, I'm wondering what are my options to show it more prominently to the user?
Context is the "local defaults" feature, where the engine finds matching values in your local .env, and applies them as default values for module constructor arg. It's pretty invasive, so tester asked to show a clear message telling you what's going on
fierce sand
got a trace link? there's telemetry.Reveal() but that might be too powerful, depending
since that one is intended for 'show this all the way from the top level, and hide any non-revealed parent spans along the way'
raven matrix
fierce sand
maybe we don't have the UI language for this yet - sounds sort of like a side hint
raven matrix
(ignore the printf fail, that's unrelated 🙂 )
And here's the parent span, representing the end user's session: https://dagger.cloud/dagger/traces/57a1f49014cb84953eafb5a7ce3c6e17?span=367488244a9e6724
At the moment my span is 3 levels of depth down
fierce sand
hmm - would it make sense as a log, somehow? like attached to load module:?
raven matrix
@fierce sand also it doesn't show up in the TUI at all, initializing module doesn't show as expandable, no matter the verbosity level
fierce sand
a very high verbosity should make it expandable - it's because it's marked encapsulate which has aged somewhat poorly, it's a bit redundant now that everything collapses by default anyway
raven matrix
Do we have the equivalent of a loglevel but for spans?
raven matrix
a very high verbosity _should_ make it expandable - it's because it's marked `en...
Ah you're right, it expands at verbosity 3
fierce sand
Do we have the equivalent of a loglevel but for spans?
unfortunately no i don't think so - might be doable with otel plumbing but it'd be pretty sophisticated
actually... vague memory of at least propagating whether debug is enabled 
but that's one specific thing, decided at command invocation time, and these logs would be somewhat hidden regardless, not sure it helps much
it seems like the hardest part of this is figuring out what exactly we want to show and when, not the mechanics of how to do it - this came from a user request? i guess the idea is to never be surprised by defaults?
will the default values not just show up automatically in the module constructor span? like daggerDev(token: Secret) - oh but that just says "Secret", maybe they'd want to see the address() equivalent, which feels like the more general problem (recognizeable high level representation of values)
raven matrix
it seems like the hardest part of this is figuring out what exactly we want to s...
yes and also being able to quickly see if you got the var name wrong
false negative, false positive
from my pov otel is an implementation detail, it's pure terminal Ux (but having it in the trace is nice too)
fierce sand
in the UI you can at least click the Secret to see its constructor, which would show that. but the TUI might show something less useful since it's not interactive at that level
raven matrix
I show the value as written in .env for example
fierce sand
(would be better to not need the interaction)
raven matrix
I guess I could pass the top level context as a special arg?
displayCtx or something
(in my core code)
I'll try that
maybe a helper callback userInfo
it would lie about the call trace though
fierce sand
there's a longstanding TODO to have a global logger - is that too big of a hammer here? (that's been the general reason for it never being TODOne despite being not hard to implement)
raven matrix
maybe on top that i make it a log, and the CLI treats top-level logs in a special way?
fierce sand
technically you'd just need to pass the root span ID down from the CLI, which could be through OTel baggage, and use it for constructing a slog.SpanLogger on the engine side. pretty sure that'd end up with the log showing up at the bottom of the TUI
i can try adding a commit for that since it's a few bespoke APIs, if that seems closest to the goal for now
raven matrix
I don't fully understand that last part, but it seems like the right direction yeah
(eg. "down from the CLI" not sure what that implies, since my code is not CLI-specific)
fierce sand
it'd show up in the same spot as the 'canceling... (interrupt again to quit immediately)` line
fierce sand
(eg. "down from the CLI" not sure what that implies, since my code is not CLI-sp...
the CLI is what creates the root span, so that's all i mean there - it controls the TUI in the end
raven matrix
I guess it would respect dagger-in-dagger? ie. my whole example trace was wrapped in a dev build of dagger dagger -c 'dev | terminal', I wouldn't want the logs to appear in the top-level dagger
fierce sand
yeah that should all work i think 
(the nested logs would go to the nested CLI)
raven matrix
nice. Yeah seems like exactly what I need then
fierce sand
@raven matrix here's this for now: https://github.com/dagger/dagger/commit/55139ea26a779ed3e96964d6a7845eb5b86accd0 - have to run out soon
raven matrix
<@488409085998530571> here's this for now: <https://github.com/dagger/dagger/com...
nice, thanks!
Will try it out tonight
OK if I just cherry-pick for now? Branch won't be mergeable for a few days anyway