Bump `uv` version to fix zig-bin installation issues
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 add --pypi zig-bin
Issue description
See that you get this error:
thread 'main' panicked at /home/runner/work/pixi/pixi/src/install_pypi.rs:1071:14:
called `Result::unwrap()` on an `Err` value: Failed to install: zig_bin-0.13.0-py3-none-manylinux2010_x86_64.manylinux_2_12_x86_64.musllinux_1_1_x86_64.http.whl (zig-bin==0.13.0)
Expected behavior
zig should install
Doing it via a task seems to work fine.
[tasks]
install-zig = "pip3 install zig-bin==0.13.0"
Bummer is I lose out on the advantage of a pixi.lock. So it works as a temporary workaround until this gets resolved.
Also another thing to note, pixi seems to get in a corrupted state when trying to install zig-bin. Deleting the pixi.lock file and recreating it after removing the dependency seems to fix it.
Hey @TCROC - do you know if this is a regression of the newest release? We updated uv so it's possible something broke.
Hey @wolfv ! :) I have reproduced it with both 0.25.0 and 0.26.1. I originally discovered it in 0.25.0 and updated to 0.26.1 hoping it would fix it but it did not :/. When was the uv change introduced?
In 0.26.0, which was released today basically.
I just tested with version 0.25.0 again and can confirm the error still exists in that version
I tried 0.23.0 as well and it still occurs. I suspect it has been here for some time if not the entire time.
This seems to be an issue with uv / the wheel itself. When I use uv to install the zig_bin I get a similar error:
uv pip install zig_bin==0.13.0
Resolved 1 package in 67ms
Prepared 1 package in 2.82s
error: Failed to install: zig_bin-0.13.0-py3-none-manylinux2010_x86_64.manylinux_2_12_x86_64.musllinux_1_1_x86_64.whl (zig-bin==0.13.0)
Caused by: The wheel is invalid: Wheel contains entry in scripts directory that is not a file: /home/zalms/miniforge3/lib/python3.10/site-packages/zig_bin-0.13.0.data/scripts/lib
@TCROC maybe you can try ziglang: https://pypi.org/project/ziglang/
@wolfv that indeed works! Thank you! :) Now I can do this as a workaround:
nushell:
$env.PATH = ($env.PATH | prepend ((python3 -m ziglang env | from json).zig_exe | dirname))
zig version
And then zig is back on my path for my godot-src project! :)
Good news: I get benefits of lockfile and such again! :)
Bad news: Its ugly because zig doesn't get installed directly to the .pixi/envs/default/bin folder. It gets installed to: /home/tcroc/dev/BlockyBallOT/submodules/godot-src/.pixi/envs/default/lib/python3.12/site-packages/ziglang/zig
I'll use this for now tho! :)
Hopefully we can still get this fixed as I expect this issue will likely arise with other pypi packages. And we may not be so lucky to have an alternative next time.
This seems to be an issue with
uv/ the wheel itself. When I useuvto install the zig_bin I get a similar error:uv pip install zig_bin==0.13.0 Resolved 1 package in 67ms Prepared 1 package in 2.82s error: Failed to install: zig_bin-0.13.0-py3-none-manylinux2010_x86_64.manylinux_2_12_x86_64.musllinux_1_1_x86_64.whl (zig-bin==0.13.0) Caused by: The wheel is invalid: Wheel contains entry in scripts directory that is not a file: /home/zalms/miniforge3/lib/python3.10/site-packages/zig_bin-0.13.0.data/scripts/lib
@baszalmstra with this being said, is there a uv repo where we should make people aware?
you could file an issue on https://github.com/astral-sh/uv :)
@wolfv Should we be closing this issue tho? Technically its still impacting pixi and may be nice to track until it gets solved. If uv for example says "won't fix" then we might want to consider alternate solutions.
can you try with pip @TCROC? I suspect it's a faulty wheel.
@wolfv pip works fine. I actually listed that as a workaround here: https://github.com/prefix-dev/pixi/issues/1650#issuecomment-2243170640
Doing it via a task seems to work fine.
[tasks] install-zig = "pip3 install zig-bin==0.13.0"Bummer is I lose out on the advantage of a pixi.lock. So it works as a temporary workaround until this gets resolved.
@wolfv
Seems like its already tracked and fixed: https://github.com/astral-sh/uv/issues/5359
@wolfv Can we reopen this issue? It looks like we need to update uv to the latest release here in pixi. Which may require some effort as sometimes updates do. Hopefully its as simple as a version bump tho! :)
@TCROC alrighty then!
@wolfv Perfect thank you! :) In hindsight I realize I spammed you with @'s. Sorry about that 😅. I was working with the godot team on an issue and didn't realize I had already @'d you twice by the time I got back around to this one.
Anywho, would you like me to change the title of the issue to something like "Update uv dependency" or something like that for better organization?
We merged the latest uv in https://github.com/prefix-dev/pixi/pull/1829 . Closing this issue, please reopen if issues still occur once a new version of pixi is released.