When we run with `-ldebug` it results in a lot of ...
# development
f
When we run with
-ldebug
it results in a lot of output (good!) from the various "threads" all interlaced with each other (good, but annoying!). Is there anyway to get a "thread id" or something added into those prints so we can try to disentangle them?
w
@curved-manchester-66006 You've got some workunit stuff with thread names, does that help out here?
c
I think adding the thread id to the log output is possible in principle, but I'm not sure of the UX of changing the format between log and debug. (Or how exactly a thread id would interact with the tokio pool offhand) I'm curious what you are trying to answer from
-ldebug
?
f
We added lots of debug output into our custom in-repo plugins.
Things like "why did it consider this a dependency?" or "why did it miss this other dependency?" or "why can't it find the correctly detected dependency?"
c
hmm, for that sort of case you want "thread id" or (not sure I have the terms right) something like "task id"? At the least, having it be possible to customize the format seems reasonable, but I'm not sure how that works with Python+Rust
f
ok, yeah, I don't know what the right term is. "`@rule` invocation id" is probably the most descriptive, but obviously doesn't mean anything to tokio
and having something more meaningful in there, like "<rule_name>:<input_file>" or something would be even better, if we're going for full customization.
c
🤔 But broadly the use case is "debug the logic in my plugin", as opposed to "why is thread X idle?" or "what is the dependency among rules?" or "what functions are hot on-cpu?"
f
yes, broadly.
dependency relationships between rules is also interesting. we have annotation magic for processes, but not rules.
c
dependency relationships between rules is also interesting.
That was somewhat leading, but I'd suggest trying the workunit logger for that.
f
what's that?
c
https://www.pantsbuild.org/stable/reference/subsystems/workunit-logger (or the recently expanded docs at https://github.com/pantsbuild/pants/pull/23285/changes ) You can plug something in and get a stream of the units of work. There is a json file one built in today. OTEL coming soon ™️ . You could plug your own internal thing in. As a conceptual/vibe level, you could imagine a visualization kinda like this or honeycomb.
f
So the old doc makes it sound like I turn it on and it just dumps stuff (json?) in a directory. The new doc makes it look like I need to make a plugin to register callbacks and generally seems like more work to get going. Is there any middle ground? 🙂
c
• Today: You can just dump json. • Today: You can write a plugin. • Soon: Built in OTEL export.