#`Print`s are not displayed in TUI

1 messages · Page 1 of 1 (latest)

primal sequoia
#

Here's a simple repro

func (m *Daggerprint) GrepDir(ctx context.Context) (string, error) {
    txt, err := dag.Container().
        From("alpine:latest").
        WithExec([]string{"echo", "THIS IS A TEXT FROM CONTAINER"}).
        Stdout(ctx)
    if err != nil {
        return "", err
    }
    fmt.Println("GrepDir called")
    fmt.Printf("List:%s\n", txt)

    return "", nil
}
#

It's also strange that if I return an empty string, I'm not able to see any of the prints even in --progress=plain. If I do return a non-empty string, I am able to see the prints but only in --progress=plain.

-v or -vvv does not show the intermediate prints

#

ok, this was because of caching. If I set +cache="never" I see the prints. Only in the following scenario. I still don't see them with -v or -vvv

It's also strange that if I return an empty string, I'm not able to see any of the prints even in --progress=plain

#

btw, this is the same behavior in v0.19.18. It's not a 19.19 specific regression

sturdy vector
#

likely because -vvv no longer means 'expand absolutely everything' because that made the other things revealed at that level practically useless, since that really opens the floodgates

#

tbh I never use higher verbosities like that because it's just too noisy, if I'm looking for something I use -E and go interactively open it

primal sequoia
#

Should't it show with -v though? -E is nice but it's not easy to figure out which one to expand. You are still kinda lost at that point.

sturdy vector
#

it would help for toplevel functions, at least, but i don't think it's a simple change

primal sequoia
#

The issue I'm facing is, in dagger there is no easy way to say "Show this msg to the user". Typically in CI we'd print a INF or WRN log. But Dagger TUI kind of gobbles it up. I understand a TUI is a different mindset for consumers and a totally new concept when it comes ti CI. Being able to show some logging to the user by default would bridge that gap IMO.

#

The TUI is super fast (which is awesome!) and it's easy to miss (or not know of) any intermediate messages/logs printed.

sturdy vector
#

Are you talking about temporary debug logs that will be deleted before committing them? Or logs that you want to leave in-place, maybe with different levels to them?

#

We have the plumbing to support it, and already use it for those somewhat crufty 'default value usage' logs, but I don't want to expose it too liberally yet since it could end up with 20% of the user's screen lost to garbage logs that a dependency somewhere deep in your DAG added and never removed (which is currently a failure mode of those 'default value usage' logs)

#

there's definitely something to do about this, but I'm not sure what yet, would need to fully understand the use case

primal sequoia
#

leave-in-place logs with different levels. I understand the forgotten (outdated) log statements dilemma as we have that problem in today's CI. But it's mostly alleviated by good review practices and regular cleanup. The type of logs I'm referring to are "info" and "debug" logs. They are ignored for the most part but very important when we want an end user to figure out the how, what, when of an issue. For example, I can talk about the thing that made me look for logs.

I am working on a module that's somewhat similar to nx affected. This is for my daggerverse repo. When I run the release, I print out during various stages what's going on. Stuff like why the CI decided to use HEAD~1 and not a tag commit for determining "baseCommit". Anyways, the technical details aren't that important. But for a user to understand why something didn't work as they expected, they'd have to look at the console log. The only way for a consumer to see the logs that the developer wanted them to see is by using --progress=plain now. Which is ok but is not a pleasant experience IMO.

If there was a way for my user to say, "run this again with debug" and get debug log statements, that would help. As I type this I also understand the issue with nested modules outputting logs that will mess up the output.

What if the log got saved to a separate file? Or a flag to indicate --log-file so that a verbose log always gets saved on disk or the engine and is able to be pulled out?

#

Maybe the answer is we change our ways and tell users to use -E. But I think even -E can be improved a bit to show more details at a top level or indicate there are logs to be viewed.

sturdy vector
#

Thanks for the details!

primal sequoia
#

I just realized.. --progress=dots shows the print statements. --progress=report does not

sturdy vector
#

ok, that matches what I thought - would have been surprised if dots didn't show it

primal sequoia
#

NP! I also wonder if this just a me problem lol

sturdy vector
#

report not showing it makes sense since it's just showing the "last frame" of the TUI

sturdy vector
#

we actually have a lot of the plumbing for this already like I said - just not a nice API. you can technically do it yourself with OpenTelemetry, we even pass along a flag through OpenTelemetry baggage indicating whether the user passed --debug

primal sequoia
#

End of the day, it's about providing end user, context so that they aren't confused at a "non-result" and runs to us platform folks.