feat: add rolling log display for build output
This PR introduces a rolling log display for build output that shows only the last 6 lines during builds, significantly reducing terminal clutter while keeping full logs available for debugging.
Previously, all build logs were either printed immediately or buffered entirely. This change adds a new RollingLogDisplay utility in the pixi_progress crate that provides a middle ground by displaying a rolling window of recent output. Each line is shown in a dimmed progress bar that automatically scrolls as new lines arrive.
The display is integrated into both source and backend build reporters. When a build succeeds, the display is quietly cleared. When a build fails, the complete log is dumped to stderr so developers have full context for debugging.
The implementation creates progress bars dynamically as lines arrive (up to 6 maximum), uses wide message formatting to prevent wrapping, and provides a zero-copy into_full_log() method for efficient error reporting.
AI Disclosure
50% Claude code / 50% Me.
@ruben-arts Let me know if this looks good in your eyes!
My first reaction is that this looks cool, but isn't too practical. The benefit of being able to scroll the current running build is more beneficial to the clean terminal for now. As I don't only want to view the logs on a failing build.
Yeah, I was thinking that we should just also always output to a log directory. That way you can always find them back. Note that if the build fails the entire output is written to the screen anyway.
Yeah, I was thinking that we should just also always output to a log directory. That way you can always find them back. Note that if the build fails the entire output is written to the screen anyway.
Fully agreed with that suggestion
Yeah, I was thinking that we should just also always output to a log directory. That way you can always find them back. Note that if the build fails the entire output is written to the screen anyway.
The failing build outputting the full log made sense to me. But it would also be needed for when I break the build by running ctrl+c as it might hang, or I want to work on it.
I really think that going this direction right now is not helpful enough, we could potentially make it opt in or use it in quiet mode. But just missing the build output was already a thing we reverted, so as soon as this is merged we would be back to that situation. I need to be able to easily inspect what is going on with the build while it's running.
As soon as pixi-build becomes much more stable, we might want to start making it less verbose and revert users to the log output. That is a feature that would be beneficial right away!
I rather remove the other process bars and only have a spinner at the bottom like cargo build.
We decided against this approach. Might revisit later.