-
Notifications
You must be signed in to change notification settings - Fork 381
feat: add rolling log display for build output #4911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Adds a RollingLogDisplay utility that shows the last 6 lines of streaming build output using progress bars. This reduces terminal clutter during builds while keeping full logs available for error reporting. Key features: - Shows up to 6 most recent log lines (dimmed) - Progress bars created dynamically as needed - Full log buffered for failure case - Uses wide_msg to prevent line wrapping - Generic utility reusable across pixi The display is integrated into SyncReporter for both source and backend builds. On success, the display is cleared. On failure, the full log is dumped to stderr.
|
@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. |
Hofer-Julian
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work, Bas! I've tested this with multiple repos and scenarios and it always did exactly what I wanted. The code changes also make sense to me. After the small leftover change is fixed, we can bring this in!
Fully agreed with that suggestion |
Hofer-Julian
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this is an improvement over the current behavior, even before we are writing logs to a file. I'd like to bring this in, feel free to chime in @ruben-arts if you disagree
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 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 |
|
We decided against this approach. Might revisit later. |
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
RollingLogDisplayutility in thepixi_progresscrate 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.