Dealing with dependency conflicts

[and800]

As we know, pip installs packages globally, unlike npm. Moreover, currently pip does not even try to deal with dependency conflicts (when you need both packages A and B, and they both depend on different versions of package C) in any way. It doesn't even notify you much about the fact it has just broken your dependencies.

Classic example, taken from here:
We develop our project or library and we need splinter and huxley as the dependencies. So we gonna install them:
$ pip install splinter
Pip installs splinter==0.7.5 and selenium==3.0.2 as splinter's dependency
$ pip install huxley

Collecting huxley
...
  Found existing installation: selenium 3.0.2
    Uninstalling selenium-3.0.2:
      Successfully uninstalled selenium-3.0.2
Successfully installed huxley-0.5 selenium-2.35.0

So we likely broke splinter, and, moreover, Pip said that everything was successfull. It even trolled us by saying successfully uninstalled package-that-we-use. And the user probably didn't notice anything, we don't read the logs line by line, when script ended successfully. It is bad.

Is it planned to define within this spec a behavior different from described above, when the packages with incompatible dependencies will be brought together in single Pipfile?

[pradyunsg]

This is really a duplicate of pypa/pip#988.

This is related to how Pipfile will behave but I don't think this issue will get fixed because of Pipfile. It'll be fixed in pip independently and ideally, that would be before Pipfile this lands.

[and800]

@pradyunsg, the reasons why I submitted this to Pipfile project are:

• Because of nature of Python packages, I don't believe that any package manager will be able to install several packages with same name and different versions in the nearest future. So the only solution is to abort potentially breaking installation, I think.
• The lock file will completely list all the packages, and only them, which have to be installed by package manager. So the conflicts must be resolved before the lock file is written. And during lock file generation, it's easy to detect these conflicts.

[kennethreitz]

This is a pip issue, not a pipfile issue.