UW Oshkosh How-To's: Tracking down pesky buildout version pins or requirements

Here are some ways to figure out the cause of conflicting version errors like this when you run buildout:

While:
  Installing client1.
Error: There is a version conflict.
We already have: Products.MimetypesRegistry 2.0.2
but Products.Archetypes 1.7.14 requires 'Products.MimetypesRegistry>=2.0.3'.

Buildout cfg files

First, check any version pins you might have in your *.cfg files.

In the above example, I would run this:

grep Products.MimetypesRegistry *.cfg

in my zinstance or zeocluster directory.  This will tell me which files refer to the offending add-on.

Extends

If the only references to the add-on correctly show the version you want (and you can't see where the wrong version is being pinned), next check if your buildout.cfg "extends" values are correctly ordered.  

If your "known good sets" ("KGS") come *after* your local version pins (in versions.cfg in the example below), you may get conflicts.

The following shows the correct ordering:

extends =
http://dist.plone.org/release/4.1.6/versions.cfghttp://good-py.appspot.com/release/dexterity/1.2.1
    versions.cfg

This is exactly what happened to me... I had a KGS for an old version of Dexterity, and it was that KGS that had a version pin that conflicted with my local pins in my versions.cfg.

Buildout can help

The way I found out that it was a KGS that was conflicting is that I ran "buildout annotate" so that it told me where its various version pins were coming from:

bin/buildout annotate

which provided this output:

...
    ...
Products.MimetypesRegistry= 2.0.2
    http://good-py.appspot.com/release/dexterity/1.0.1?plone=4.1
...
    ...