Pip respects == but requirements.txt can override. On May 16, 2013, at 9:51 AM, Daniel Holth <dho...@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 <j...@zope.com> wrote: >> On Tue, May 14, 2013 at 10:36 PM, Daniel Holth <dho...@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 <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 >> >> >> >> -- >> 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
