This is a mental note on a topic I realise needing a discussion while working on another issue.
Say we have package foo and bar with the following dependencies:
foo 1.0.0
six<1.12
foo 2.0.0
six>=1.12
bar 1.0.0
six<1.12
bar 2.0.0
six>=1.12
Given an environment with the followings installed:
foo 1.0.0
bar 1.0.0
six 1.11.0
and the user runs pip install --upgrade foo. What should we do? If we upgrade foo to 2.0.0, six needs to be upgraded as well (as an intrinsic requirement), but now it would conflict with bar. I can think of three possibile approaches:
foo and six, and print an error/warning telling the user bar now has unsatisfied requirements.bar automatically to 2.0.0.foo 1.0.0 is the latest version without conflicts.Approach 1 is the simplest, but might be too difficult for the user to notice (especially on CI). This is probably not a good idea if we can avoid it.
Approach 2 looks like a good idea at first glance, but IMO may be confusing to the user. The dependency graph would be much less complex in more than one way in practice, and it would be difficult for the user to notice, or understand why a seemingly unrelated package got upgraded.
Approach 3 is “correct” in thoery, but is as unuseful to the user as pip’s famous “No matching distributions found for” error. There is clearly a newer version to upgrade to from the user’s perspective. Why is pip not finding it? Open GitHub and file a bug report.
Approach 4 is the most reasonable to me. In the above example, pip would emit something like six>=1.12 (required by foo) would cause incompatibility in bar (requires six<1.12). The downside is pip would need to do more work to interpret the resolution result (this does not fit into the resolution process IMO).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4