[Distutils] Overriding dependency versions

[Jim Fulton]

On Mon, May 13, 2013 at 10:16 AM, Ian Cordasco
<graffatcolmingov at gmail.com> wrote:
> On Mon, May 13, 2013 at 10:12 AM, Reinout van Rees <reinout at vanrees.org> wrote:
>> On 13-05-13 15:57, Ian Cordasco wrote:
>>>
>>> If I release a library dependent upon a particular API in one version
>>> of a dependency and before I release my next version I notice plans to
>>> break the existing API, why shouldn't I pin the version to protect
>>> users (or at least provide a maximum version) from getting horrible
>>> exceptions?
>>
>>
>> Best example: if you pin "somelibrary=1.2" in your library, none of your
>> users can use the critical 1.2.1 bugfix release.
>
> Thanks to you and Daniel. (I accidentally replied to Daniel off-list.)
> I had just been advised by someone formerly a part of the distutils
> (or distribute, I forget which) team that you either pin or don't. I
> try not to, but there have been occasions where I found it necessary.
> I'll certainly move forward a better developer for your explanations.

<soapbox>Unfortunately, when people discuss solutions, they often
forget to state the problem they're thinking of.</soapbox>

As Daniel pointed out, when deploying an *application*, you should
generally pin all of your dependencies, so you can reproduce the
deployment.  This can be done via the apps setup.cfg, pip requirements
or buildout versions.

When releasing libraries, you should restrict versions as little as
possible. The more you restrict dependency versions, the harder your
library is to use. A common recommendation is to set a minimum version
to the lowest version of the dependency known to work and to set the
maximum version to less then the next major release:

  >=2, <3dev

In practice, most people just set a lower bound, if any.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton