https://pantsbuild.org/ logo
Join Slack
Powered by
With <https://github.com/pantsbuild/pants/issues/1...
# development
h
With https://github.com/pantsbuild/pants/issues/11433 (making streaming workunit handler be async), there's a problem: console output/logging goes to 
pants.log
instead of the console. That means, for example, that making 
--stats-log
be async in the final call results in the result being written to the file Would it be possible to have workunit handler plugins write to the console somehow? I don't understand much how that split works
cc @witty-crayon-22786
Possibly related, right now, the workunit thread dying does not propagate to the Pants run - should it?
w
it shouldn’t kill the foreground run, no. should log noisily though.
um. so how log destinations work post #11536 is that each thread is associated with a particular destination
threads and tasks spawned on the rust side copy that association along
because the SWH thread is spawned on the python side, the association isn’t copied. we could add an API to do that
👍 1
but, as you pointed out: where would the stats-log output go if it completed asynchronously? it can’t go to the console anymore: that’s gone.
so that may be an independent problem (depending on whether all SWH logging should go to the foreground while it is available… most of it would probably be fine to go to the log)
h
When you're using Pantsd, does the console go away after a run? Because with non-pantsd mode, the current strategy with #11433 is to continue blocking on the SWH finishing before finishing the overall Pants run
w
When you’re using Pantsd, does the console go away after a run?
yes, it goes away. we atomically switch to logging when the client disconnects
🤔 1
it’s the only way… you can’t keep writing to the console after the client has moved on to other things.
(you could, but people would absolutely view it as a bug.)
👍 1
h
Yeah, that makes sense. That would be really trippy for my terminal to show Pants is done, but it still keeps printing stuff to the screen
So, I wonder if perhaps we need to have a way for some workunit handlers to say they must log to the console so must be blocked? 
--stats-log
must be blocked, whereas Toolchain's can be async
w
sorry, i just realized that this question is maybe confusing: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1615316299081400?thread_ts=1615316068.080000&amp;cid=C0D7TNJHL … iff we joined before it completed it would go to the console, otherwise it would automatically go to the log.
👍 1
yea, possibly.
h
Based on the above, my thoughts on a path forward: 1. Change workunit handlers to log to console when the console is live 2. allow handlers to indicate whether they must be blocking (--stats-log) or can be async Wdyt? @witty-crayon-22786
w
yea, seems reasonable.
h
Cool. I don't know how to get started on https://pantsbuild.slack.com/archives/C0D7TNJHL/p1615316256081100?thread_ts=1615316068.080000&amp;cid=C0D7TNJHL Would you be willing to please write some thoughts if you have an idea for how to do it?
w
probably the way to go about that is to add wrapper a Python wrapper type for 
Arc<Destination>
, and then expose 
get_destination
and 
set_destination
(https://github.com/pantsbuild/pants/blob/3e7e97a267582dc5e7c1bbce27a3b17d6e315c3a/src/rust/engine/stdio/src/lib.rs#L428-L437) to python
then you’d get_destination in the thread starting the SWH thread, and set_destination in the SWH thread
👍 1
Open in Slack
PreviousNext
Powered by