Is `pixi global upgrade-all` broken?
Checks
- [x] I have checked that this issue has not already been reported.
- [x] I have confirmed this bug exists on the latest version of pixi, using
pixi --version.
Reproducible example
pixi global upgrade-all on Linux with pixi=0.30.0
Issue description
I have pixi==0.30.0 installed on Linux, and pixi global upgrade-all behaves somewhat weirdly as if there are some issues related to multithreading execution. This makes it a bit tricky to make a proper bug report.
When I run the command:
- It can hang for some time without any output.
- Then a number of
solving environmentlines appears & disapper and it looks like some work is being done. - Then a progress bar appears like something is being downloaded.
- Then suddenty everything stops at random moment without any final message, and the output remains in its intermediate state.
For example, I have just run the command and this is how the final output looks like for me (to clarify, the command already finished its execution, so it is the final output).
$ pixi global upgrade-all
}⠁
⠤ solving environment
⠴ solving environment
⠲ solving environment
⠲ solving environment
⠒ solving environment
installing packages [00:00:00] [━━━━━━━━━━━━━━━━━━━━] 8/8 libgcc
and it is unclear whether anything was updated or not. Sometimes the whole thing fails because of a panic, but I cannot reliably reproduce this.
P.S. I also have tested the command on my macOS machine, and it seems to function properly, but I have only two global packages installed and this may not be a proper stress test.
Expected behavior
Thanks for the ping, this issue is indeed hard to reproduce, I think it has to do with our reporting. We'll release https://github.com/prefix-dev/pixi/milestone/9 really soon (think days). Which means this is going to be completely different in implementation.
I see, thanks for the prompt reply!
Just in case, sharing the panic message that I just encountered by running pixi global upgrade-all with pixi=0.31.0 on Linux:
thread 'main' panicked at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rattler-0.27.14/src/install/clobber_registry.rs:120:65:
entry must exist
(I tried to obtain the full traceback by rerunning the command with RUST_BACKTRACE=1 many times, but the issue does not reproduce)
I've unfortunately had the same issue. I've spend 1 hour debugging this yesterday but because the part creating the issue was fixed I'm unable to make a reproducer.
The fix is to throw away the environment directory. I'll see if I can work on a fix that avoids this panic completely!
For devs: It comes down to this function:
https://github.com/conda/rattler/blob/0cacc4b66903aea0ce65e1c1283314b50440f6ae/crates/rattler/src/install/clobber_registry.rs#L113-L125
The original_path is the path without the "__clobber..." in it but that was already removed, here we need to remove the path with clobber in it. This can be left over as the only file because of bugs in earlier versions. So this expect is pretty likely to be reached. I've tried to improve the error but the design of the function is just not correct. @wolfv Could you give some input on how to properly fix it?
This is fixed by the latest rattler / pixi releases :)