Why don't we simply provide an option to ignore == if it is not a "root" dependency?
On Mon, May 13, 2013 at 2:02 PM, Jim Fulton <j...@zope.com> wrote: > On Mon, May 13, 2013 at 10:16 AM, Ian Cordasco > <graffatcolmin...@gmail.com> wrote: >> On Mon, May 13, 2013 at 10:12 AM, Reinout van Rees <rein...@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@python.org > http://mail.python.org/mailman/listinfo/distutils-sig _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
