Skip to content

Conversation

@baszalmstra
Copy link
Contributor

@baszalmstra baszalmstra commented Nov 11, 2025

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.

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.
@baszalmstra
Copy link
Contributor Author

@ruben-arts Let me know if this looks good in your eyes!

@ruben-arts
Copy link
Contributor

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.

@baszalmstra
Copy link
Contributor Author

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.

Copy link
Contributor

@Hofer-Julian Hofer-Julian left a 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!

@Hofer-Julian
Copy link
Contributor

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

Copy link
Contributor

@Hofer-Julian Hofer-Julian left a 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

@ruben-arts
Copy link
Contributor

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.

@lucascolley lucascolley added enhancement New features cli Issue related to CLI area:build Related to pixi build UX Related to the User Experience of pixi labels Nov 16, 2025
@baszalmstra
Copy link
Contributor Author

We decided against this approach. Might revisit later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:build Related to pixi build cli Issue related to CLI enhancement New features UX Related to the User Experience of pixi

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants