Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Disallow explicitly passing install-location-related arguments in --install-options #7309
What's the problem this feature will solve?
then it causes issues. Not every package uses
Pip knows how to use scheme information properly for PEP 517, wheel, and legacy installs. Enforcing that pip is the only one passing this kind of information will make the user experience more consistent.
Describe the solution you'd like
In addition to the consistent user experience, this would also allow pip to pass the more explicit
This may also be required to implement PEP 582 (
IMO this could be implemented without deprecation because the current behavior demonstrated in #7253 and #7240 causes failures in non-obvious ways, and the remediation is simple in most cases - just pass the parameters to pip instead.
I don't think this is an extension of #6606 -- that PR changed when pip used PEP 517, which is something we're still working on. This, however, affects everyone on the legacy code path. We'd be removing functionality that user might depend on directly, so we should go through the deprecation cycle for it.
FWIW, I now know that basically any change in pip's build logic will affect someone (i.e. break their deployment / CI pipeline) and they're usually not happy about it. With the power of retrospect, I feel we should've gone for at least short deprecation cycle (1 release) for #6606 since that was a (minor) change in end-user-affecting behavior as well.
OK. After thinking on it more, we can communicate the workaround in the deprecation notice. Hopefully that means currently impacted users will not have to search the issue tracker when some packages are missing, so I don't mind that approach as much as I did initially. It might even be worth including in a fix release for 19.3? Then we could also close #7240.
Given that we've already closed that issue (which is a form of communication on our release processes), I'm inclined to say no -- but it's really an RM's decision so... pinging @xavfernandez! :P
FWIW, I'm in no hurry to close #7240 but yes, even the deprecation messaging is enough to justify closing it.
I'm on board with forbidding conflicting options in
After talking this over with @pradyunsg, our conclusions are:
For the more fine-grained option handling, I'm thinking the following:
install options mapped to pip options
if provided in any
install options that override scheme values directly
If provided in any
unsupported install options
These options, which do not have an equivalent in the scheme that we install packages to, are unsupported and if they are provided in any
Just to reiterate why this is important: once the above is in place, we would be able to do the following: