I have not changed requirements in my Divio project, so why does the build fail with a dependency conflict?

Question

The last time I deployed the project, the build worked perfectly.

In the meantime I have changed nothing that would affect the pip requirements, yet I get an error when building:

Could not find a version that matches Django<1.10,<1.10.999,<1.11,
<1.12,<1.9.999,<2,<2.0,==1.9.13,>1.3,>=1.11,>=1.3,>=1.4,>=1.4.10,
>=1.4.2,>=1.5,>=1.6,>=1.7,>=1.8

I get the same error when building the project locally with docker-compose build web .

What could be the problem?

Answer 1

The problem here is that although you may not have modified any requirements, the dependencies of a project can sometimes change on their own.

You may even have pinned all of your own requirements (which is generally a good idea) but that still won't help if one of them itself has an unpinned dependency.

Anywhere an unpinned dependency exists, you can run into this.

Here's an example. Suppose your requirements.in contains super-django==1.2.4 . That's better than simply specifying super-django , as you won't be taken by surprised if a new, incompatible version of the Super Django package is released.

But suppose that in turn Super Django 1.2.4, in its requirements, lists:

Django==1.11
django-super-admin

If a new version of Django Super Admin is released, that requires say Django>=2.0 , your next build will fail because of the mutually exclusive requirements.

To track down the culprit when you run into such a failure, you need to examine the build logs. You'll see there something like:

Could not find a version that matches Django==1.11,>=2.0 [etc].

So now you know to look back through the logs to find what is wanting to install Django>=2.0 , and you'll find:

adding Django>=2.0
  from django-super-admin==1.7.0

So now you know that it's django-super-admin==1.7.0 that is the key. Since you can't trust super-django to pin the correct version of django-super-admin , you'll have to do it yourself, by adding django-super-admin<1.7.0 to the requirements.in of your project.

There's more information about this at How to identify and resolve a dependency conflict .

You can also Pin all of your project's Python dependencies to ensure this never happens again with any other dependency, though you sacrifice some flexibility for the guarantee.

---

Note: I am a member of the Divio team. This question is one that we see quite regularly via our support channels.