-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Allow to use --only-binary=:all: but exclude a few packages. #12348
Comments
I have hit similar issues, so I'm in favour of the idea in principle. However, I think our options in this area are already rather complex and confusing (the differences and interactions between I'm conscious though that "the perfect is the enemy of the good" and "practicality beats purity", so I don't want to get side-tracked designing some sort of selection language rather than just fixing the issue - but I do think we should at least consider a more general mechanism, rather than just adding more technical debt. Also relevant here is the discussion in #9140. |
Thanks, I agree but took a conservative stance in my issue. I think a mini
language say +foo -foo ~foo in addition to :all: :none: could maybe work.
It could be an exclusive flag with a long deprecation period.
Also if we look at wider problem, should this be extends to requirements
file (i'm inclined to say no) or just pip cli ?
I also have the vague impression that we might be able to solve as well
without adding new flags. as :none: empties the current set we could have
--no-binary foo,:none:,bar "remove" foo from the only binary set. I don't
like it, but it does not add any external things and rely on the fact that
if something is both only binary and no binary, you will never be able to
find a viable source.
…On Fri, Oct 13, 2023 at 17:24 Paul Moore ***@***.***> wrote:
I have hit similar issues, so I'm in favour of the idea in principle.
However, I think our options in this area are already rather complex and
confusing (the differences and interactions between --only-binary,
--prefer-binary, and --no-binary are far from obvious). I think we should
be cautious about simply adding new options here, and maybe instead we
should work out some form of replacement syntax that allows the user to
describe clearly what they want.
I'm conscious though that "the perfect is the enemy of the good" and
"practicality beats purity", so I don't want to get side-tracked designing
some sort of selection language rather than just fixing the issue - but I
do think we should at least *consider* a more general mechanism, rather
than just adding more technical debt.
Also relevant here is the discussion in #9140
<#9140>.
—
Reply to this email directly, view it on GitHub
<#12348 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACR5T4NPEQMQHXYOZZUVQLX7FML3AVCNFSM6AAAAAA57DDIDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRRG4YDAOJZGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
This would be great!!! I also kind of like:
to exclude |
hi there, I just filed #13077, because, at least for me using the Irrespective of the current behaviour, I agree with the other suggestions here for a more intuitive way to do this would be good, especially because of the |
What's the problem this feature will solve?
I like to have
--only-binaries=:all:
, especially in CI, but not all packages are availlable as binary everywhere (especially since 3.12 is recent).I'd like to say "all binary, except for X, Y, Z". doing
--only-binaries=:all: --no-binary=X,Y,Z
does not cut it as now on older Python where binary is available it will still use the TGZ.Describe the solution you'd like
Either a flag
--binary-or-source=X,Y,Z
, or a syntax to say--only-binary=:all:,-X,-Y,-Z
Note that this is different from
--prefer-binary
.Alternative Solutions
:all:
.It is impractical because of the potential CLI length, and recursive dependencies that may change.
Additional context
I believe that should not be too invasive of a change as most changes should be on the
FormatControl
class if my understanding is correct.Code of Conduct
The text was updated successfully, but these errors were encountered: