--no-binary affects later pip install without that flag #7506
Comments
|
I believe this is documented: https://docs.astral.sh/uv/pip/compatibility/#-no-binary-enforcement |
|
I went directly to https://docs.astral.sh/uv/reference/cli/#uv-pip-install and didn't see anything relevant and never thought to look for the page you mention. It might help if that information is part of the command docs or linked to.
Well this is the opposite case but the same logic must apply, I see now. It seems to me that |
I'm a little confused how this is different to pip, which will also use a binary cache even when @RazerM Do you not have this same issue with pip then? |
|
@notatallshaw That's different. That issue is complaining that a subsequent pip does not use what it built from |
|
Re-reading the issue, I don't know if I agree with the premise. If you run What I could imagine though is: if the user runs |
I agree with this. What about The |
I think the logging needs to be better then. There's no indication that uv is using a wheel it built earlier from an sdist. As I said at the end of my post you see the filename of a wheel which is what you expect to be installed: Whereas the wheel that was built should look like (I assume uv is just using the logged wheel for metadata, but it's not clear). I'd like to see the name of the cached wheel that is being used if possible, or maybe just that it's using the cached build of an sdist. |
can i second this? if i run perhaps there could be a warning: > uv pip install basedmypy --no-binary :all:
Resolved 4 packages in 474ms
WARNING: reusing binary edition from cache
Installed 1 package in 3.89s
+ basedmypy==2.6.0additionally, there could be a "work properly" > uv pip install basedmypy --no-binary :all: --no-binary-force # force???you could just use > uv pip install basedmypy --no-binary :all: --no-cache
Resolved 4 packages in 524ms
Built basedmypy==2.6.0
Prepared 1 package in 3m 54s
Installed 1 package in 2.47s
+ basedmypy==2.6.0 |
|
Isn't |
|
i was referring to the caching of the sdist build, being forced to use > uv pip install basedmypy --no-binary basedmypy
Resolved 4 packages in 686ms
Built basedmypy==2.6.0
Prepared 1 package in 1m 26s
Installed 1 package in 2.98s
+ basedmypy==2.6.0
> uv pip uninstall basedmypy
Uninstalled 1 package in 2.85s
- basedmypy==2.6.0
> uv pip install basedmypy --no-binary basedmypy
Resolved 4 packages in 10ms
Installed 1 package in 2.68s
+ basedmypy==2.6.0 |
|
although what is alarming to me is that > uv pip install basedmypy --no-binary basedmypy
... # builds, caches and installs sdist
> cd ../other-project
> uv pip install basedmypy --only-binary basedmypy
... # installs cached sdist |
|
I think what you're describing is something else, and it was fixed in #7772 (not yet released). You want to avoid using cached registry-binaries when you run with |
Version: uv 0.4.11
When
--no-binaryis used, some packages run a compiler during package installation, but others just ship a Python fallback in their sdist.An example of which is black. If I install it with
--no-binary black, then a later install without this flag gets the cached copy without compiled extensions – I found this quite surprising:I thought uv was broken, the install with
-vsaysDEBUG Selecting: black==24.8.0 [compatible] (black-24.8.0-cp312-cp312-macosx_11_0_arm64.whl)and then there aren't any shared object files installedshow full log
The text was updated successfully, but these errors were encountered: