Requirements with (potentially conflicting) options

This is a scenario which may never happen in practice, but for which we need to decide what a reasonable behaviour would look like. The current resolver probably does “something”, but likely by accident of implementation. For the new resolver, though, this question may directly impact the implementation strategy.

Consider if the user has two requirements file something like this:

r1.txt:

foo --install-options option1

r2.txt

foo --install-options option2

and then suppose the user does an install as follows:

$ pip install -r r1.txt -r r2.txt

Basically, we now have two InstallRequirement objects, both for foo, but with different install options. Which one gets installed? How do we choose?

The current resolver appears (from my experiments) to pick the first one (option1). But the new resolver would end up creating a set of Candidate objects for foo - and which set of options should it choose to apply when preparing/building those candidates?

The problem here is very much that the new resolver will do find_matches against both requirements, and get 2 lists of Candidates. We need to merge those lists, as they will basically contain the same candidates. But if we merge, we have to decide which options to keep and which to discard.

I’m inclined to do as the current resolver does and just take the first set of options that the code encounters, but say that this is explicitly “not supported” in the sense that we don’t guarantee any particular behaviour. I doubt it will cause anyone any issues in practice.

Ideally we could detect and warn/error on conflicts, but I don’t know if that’s practical (I chose install options as an easy to describe case, but really any configuration held in an InstallRequirement would have the same issue (markers, the isolated flag, hash options, the wheel cache…).

[uranusjr]

The prompt would be nicer to have, but IMO it is better to error out than prompt the user if the conflicting options come from a requirements file (the user should fix it), so that would be my choice to implement first.

[brainwane]

Legacy pip has inconsistent behavior and the new resolver will act differently; we’re moving this to fix post-release, and as we get more user feedback we’ll know more about what to provide errors/notifications about.