nix flake show prints log on same lines as output instead of clearing. #425

Closed
opened 2024-06-26 22:31:26 +00:00 by whovian9369 · 9 comments
Member

Describe the bug

When using nix flake show (as that's all I've tested with), the evaluation log output is not correctly cleared as would be expected.

Steps To Reproduce

  1. Print a flake's outputs using nix flake show

Expected behavior

Output was expected to be printed without log messages staying in output lines.

nix --version output

nix (Lix, like Nix) 2.91.0-dev-pre20240624-d5637ee

Additional context

Here's some example outputs of current behaviour:

$ nix flake show
 path:/home/whovian/.flakes/temp?lastModified=1719437134&narHash=sha256-JoBipcHBsDwEHIRgmf6EqM4rNxgvvjBHohnhUyf6rJo%3D
 evaluating ''└───packages
 evaluating 'packages'    └───x86_64-linux
 evaluating 'packages.x86_64-linux'        ├───default: package 'rom-properties-git'
 evaluating 'packages.x86_64-linux.default'        ├───rom-properties_gtracker: package 'rom-properties-git'
 evaluating 'packages.x86_64-linux.rom-properties_gtracker'        ├───rom-properties_ninja: package 'rom-properties-git'
 evaluating 'packages.x86_64-linux.rom-properties_ninja'        └───rom-properties_ninja_gtracker: package 'rom-properties-git'

$  nix flake show
 path:/home/whovian/.flakes/temp?lastModified=1719437642&narHash=sha256-NwVUfxxpx/XDPwBnLbv5FB5ldzgYs67wNgQlKvUMnl4%3D
 evaluating ''└───packages
 evaluating 'packages'    └───x86_64-linux
 evaluating 'packages.x86_64-linux'        └───default: package 'binaryobjectscanner-3.1.13'
## Describe the bug When using `nix flake show` (as that's all I've tested with), the evaluation log output is not correctly cleared as would be expected. ## Steps To Reproduce 1. Print a flake's outputs using `nix flake show` ## Expected behavior Output was expected to be printed without log messages staying in output lines. ## `nix --version` output `nix (Lix, like Nix) 2.91.0-dev-pre20240624-d5637ee` ## Additional context Here's some example outputs of current behaviour: ``` $ nix flake show path:/home/whovian/.flakes/temp?lastModified=1719437134&narHash=sha256-JoBipcHBsDwEHIRgmf6EqM4rNxgvvjBHohnhUyf6rJo%3D evaluating ''└───packages evaluating 'packages' └───x86_64-linux evaluating 'packages.x86_64-linux' ├───default: package 'rom-properties-git' evaluating 'packages.x86_64-linux.default' ├───rom-properties_gtracker: package 'rom-properties-git' evaluating 'packages.x86_64-linux.rom-properties_gtracker' ├───rom-properties_ninja: package 'rom-properties-git' evaluating 'packages.x86_64-linux.rom-properties_ninja' └───rom-properties_ninja_gtracker: package 'rom-properties-git' $ nix flake show path:/home/whovian/.flakes/temp?lastModified=1719437642&narHash=sha256-NwVUfxxpx/XDPwBnLbv5FB5ldzgYs67wNgQlKvUMnl4%3D evaluating ''└───packages evaluating 'packages' └───x86_64-linux evaluating 'packages.x86_64-linux' └───default: package 'binaryobjectscanner-3.1.13' ```
whovian9369 added the
bug
label 2024-06-26 22:31:26 +00:00
Owner

@kloenk could this be related to the progress bar refactors? that was the only bigger change in this area of the code recently (and since it's already caused behavioral changes like #424 it seems plausible that we missed things in review?)

@kloenk could this be related to the progress bar refactors? that was the only bigger change in this area of the code recently (and since it's already caused behavioral changes like #424 it seems plausible that we missed things in review?)
Owner

i hit this yesterday as well. plausible it's a progress bar behaviour change.

i hit this yesterday as well. plausible it's a progress bar behaviour change.
Author
Member

As an update, I'm doing some builds locally and 697ef65c14 does not appear to suffer from this issue. (Thank you pennae for mentioning the progress bar changes that led me to trying this specific commit.)
I'll keep doing some manual bisects to see what I can figure out on my end.

EDIT: e44dcd63c4 seems to be fine too.
EDIT: 37f276ba9d seems to have this issue, so going to keep bisecting.
EDIT: e09cc60df9 seems to have this issue, so going to keep bisecting.
EDIT: 375f4c0337 seems to be fine!

EDIT: After my own bisection efforts, I'm pretty sure that da4e46dd1f introduced the issue. Can't confirm it 100% or write a fix, but I'm pretty sure that's it based on the findings.

As an update, I'm doing some builds locally and 697ef65c148a48e5d8255b6425b6ca3a5b7d0be8 does _not_ appear to suffer from this issue. (Thank you pennae for mentioning the progress bar changes that led me to trying this specific commit.) I'll keep doing some manual bisects to see what I can figure out on my end. EDIT: e44dcd63c4d96807536cdcf2afb688a537cce9be seems to be fine too. EDIT: 37f276ba9d1856a6093e0d347224ab7c1982e75f seems to have this issue, so going to keep bisecting. EDIT: e09cc60df9698f268fa06ed1d9879101687b9eff seems to have this issue, so going to keep bisecting. EDIT: 375f4c033753db2c20af398211e892ddc9d29ec1 seems to be fine! EDIT: After my own bisection efforts, I'm pretty sure that da4e46dd1fc04067b5ba4bc16dd68134fa7efad2 introduced the issue. Can't confirm it 100% or write a fix, but I'm pretty sure that's it based on the findings.
Member

Eh yeah quite possible that it's from there. thought I tested that as well, but guess it got lost. Will try to come up with a fix when I have the time

Eh yeah quite possible that it's from there. thought I tested that as well, but guess it got lost. Will try to come up with a fix when I have the time
Author
Member

This also appears to affect nix search nixpkgs {search_term_here}, so it definitely seems to be related to Flakes in general, instead of just nix flake commands like I had hoped.
I know that was likely expected from the start, but figured it good to update here anyway.

This also appears to affect `nix search nixpkgs {search_term_here}`, so it definitely seems to be related to Flakes in general, instead of just `nix flake` commands like I had hoped. I know that was likely expected from the start, but figured it good to update here anyway.
Author
Member

Seems to be fixed for me, after I did a rebuild ~20 hours ago.

$  nix --version
nix (Lix, like Nix) 2.91.0-dev-pre20240626-5dc85e8

$ nix flake show
path:/home/whovian/.flakes/temp?lastModified=1719437642&narHash=sha256-NwVUfxxpx/XDPwBnLbv5FB5ldzgYs67wNgQlKvUMnl4%3D
└───packages
    └───x86_64-linux
        └───default: package 'binaryobjectscanner-3.1.13'

Edit: Just checked out the Lix commit ID against the currently pushed commits, and logically there's no reason that this should have fixed itself. I'm quite confused now...

Seems to be fixed for me, after I did a rebuild ~20 hours ago. ``` $ nix --version nix (Lix, like Nix) 2.91.0-dev-pre20240626-5dc85e8 $ nix flake show path:/home/whovian/.flakes/temp?lastModified=1719437642&narHash=sha256-NwVUfxxpx/XDPwBnLbv5FB5ldzgYs67wNgQlKvUMnl4%3D └───packages └───x86_64-linux └───default: package 'binaryobjectscanner-3.1.13' ``` Edit: Just checked out the Lix commit ID against the currently pushed commits, and logically there's no reason that this should have fixed itself. I'm quite confused now...
Owner

confirmed, seems fixed on my machine, gonna close

confirmed, seems fixed on my machine, gonna close
jade closed this issue 2024-06-30 07:31:53 +00:00
Owner

fix commit was 3dd7d023f4

fix commit was 3dd7d023f496d97bc9cb1a5fcf889acccfd4a711
Member

This issue was mentioned on Gerrit on the following CLs:

<!-- GERRIT_LINKBOT: {"cls": [{"backlink": "https://gerrit.lix.systems/c/lix/+/1561", "number": 1561, "kind": "commit message"}], "cl_meta": {"1561": {"change_title": "libmain: better fix for #424, #425"}}} --> This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/1561](https://gerrit.lix.systems/c/lix/+/1561) ("libmain: better fix for #424, #425")
Sign in to join this conversation.
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#425
No description provided.