[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