Missing an option to prioritize --find-links over --index-url

• Pip version: master (f1d0939d63267ec186d7aad07862922f37b3a1e1)
• Python version: any
• Operating system: any

Description:

There is no option to force precedence of a wheelhouse passed to --find-links over --index-url (or default index). There is option to disable index completely, but it isn’t always desired if you’d like to keep the default index as a fallback for any packages that are not in the wheelhouse.

This stems from the order being hardcoded here: https://github.com/pypa/pip/blob/f1d0939d63267ec186d7aad07862922f37b3a1e1/pip/index.py#L398-L405

It would be great if this order would be configurable.

[alecbz]

If I’m understanding the original snippet correctly, packages found via index URLs will always be preferred over ones locally available, in the case where --find-links is used and --no-index is not?

At the very least, I think this deserves to be documented somewhere. This feels like very surprising behavior.

My use-case: I compiled tensorflow to take advantage of certain CPU features, and put the wheel into our local wheel directory. But pip happily continued to install the version available at pypi and ignored the one I built locally.

I’m not sure what the right answer is here. Would --prefer-binary help at all? I’m not sure if the version of tensorflow available on pypi is a source or binary wheel. I think maybe the best answer is to revert to using --no-index, but that means we need to pull down more wheels locally than we would have otherwise wanted.

I suppose using --hash is maybe another option?

[alecbz]

(and IMO, it’s pretty self-evident - if the version, name and target environment are the same, how else should we choose between 2 wheels?)

By preferring a local wheel to one fetched from a remote? 😃

I agree that it’s very desirable for this to be a true property of versioning systems, but it seems important to take note when it’s not the case, and either:

• try to provision for the fact that it is not the case, by, e.g., adding features like the one proposed in this issue
• or, try to fix the fact that it’s not always the case, by, e.g., documenting that this is in fact the intended behavior, adding features to tooling to catch these bugs when they occur (pip could maybe report a warning when it encounters two wheels that differ), making it easier to add build metadata when packaging a wheel (since it is often likely necessary to preserve this property), etc.