-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Allow --no-binary <package>
to override --only-binary :all:
#4063
Comments
Looking into this... |
I put up a draft at #4067 Implementation wise this isn't too difficult. I'm unsure of the ramifications though. |
I swear I only glanced away from my emails for a moment between "Looking into this..." and "I put up a draft" 😆
I agree it's not clear that this is what the user would want 100% of the time, but I think it does makes sense that the more specific requirement would override the less specific requirement. If it's not agreed that uv should allow this, I think it would make sense to throw an immediate error on specifying |
:) Yeah we should definitely improve the error instead of attempting to resolve. I'll open some issues around that. |
My use case is in general I do not want to use sdists, but there are a small number of exceptions to this rule, either because sdists are required, or because I am referencing local sources.
So I either want to be able to say "only use an sdist if no wheel is available at all", or I want to say "only use an sdist for this list of explicit packages".
Pip allows both of these behaviors, the first can be achieved with
--prefer-binary
which has been discussed here: #1794, and it appears it would be difficult for uv to support given it's design choices.The second can be achieved by using
--no-binary <package>
to override:--only-binary :all:
(though I have not checked if this is intentional or not, for pip I generally rely on--prefer-binary
), e.g.But for uv this appears to fail:
But let me know if there's a better solution for my use case.
The text was updated successfully, but these errors were encountered: