[Distutils] Overriding dependency versions

Donald Stufft donald at stufft.io
Thu May 16 15:57:49 CEST 2013


Pip respects == but requirements.txt can override. 

On May 16, 2013, at 9:51 AM, Daniel Holth <dholth at gmail.com> wrote:

> If you were to say:
> 
> install gerbil==3 wheel==0.16
> 
> and gerbil version 3's requirements were:
> 
> water_bottle == 4
> shavings < 7
> wheel >= 0.16 # of course
> 
> and shavings's requirements were:
> 
> cedar == 0.9
> 
> The root of the dependency graph is "gerbil==3 wheel==0.16.0". These
> are the only == constraints that will be honored.
> 
> The proposed option would keep "gerbil==3 wheel==0.16.0", convert
> water_bottle==4 and cedar==0.9 to just water_bottle and cedar, and
> respect the >= and < constraints.
> 
> 
> On Thu, May 16, 2013 at 9:31 AM, Jim Fulton <jim at zope.com> wrote:
>> On Tue, May 14, 2013 at 10:36 PM, Daniel Holth <dholth at gmail.com> wrote:
>>> Why don't we simply provide an option to ignore == if it is not a
>>> "root" dependency?
>> 
>> I don't understand what you mean.
>> 
>> Jim
>> 
>>> 
>>> On Mon, May 13, 2013 at 2:02 PM, Jim Fulton <jim at zope.com> wrote:
>>>> 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
>>>> _______________________________________________
>>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>>> http://mail.python.org/mailman/listinfo/distutils-sig
>> 
>> 
>> 
>> --
>> Jim Fulton
>> http://www.linkedin.com/in/jimfulton
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


More information about the Distutils-SIG mailing list