Hi there,

While Jim expected to see some form of fireworks in the distutils discussion that I started about the requirement to pin down eggs while still leaving flexibility for those who want it, I think we've come to an early conclusion.


Philip Eby responded and said that my use cases could be served if we could 'or' version requirements. He expects that to be in setuptools 0.7.

My main use case: I want the ability to release packages that depend on other packages. I want to be able to specify exactly which versions of my dependencies I want to use in my package's setup.py. I could do this today, but then I would block any use of my package that diverged even in a minimal way by people who know what they are doing.

I will give an example:

Loose requirements (current practice) in setup.py:

   install_requires = [
     'foo',        # any foo should do
     'bar >= 1.3', # I need a change introduced in 1.3
   ]

Hard requirements (but lost flexibility) in setup.py:

   install_requires = [
      'foo == 1.1',
      'bar == 1.3.1',
   ]

Using 'or' to combine these requirements, hypothetical syntax:

   install_requires = [
      'foo or foo == 1.1',
      'bar >= 1.3 or 1.3.1',
   ]

Now if we taught setuptools or distutils to have a mode where it looks for the most specific in the 'or' clauses, we have a way forward, as it would get exactly those versions I said I prefer, meaning that as long as people install my package that way, it should continue to work.

Of course there's the case of nested dependencies, what if I have package A which says:

   install_requires = [
      'B or B == 1.3',
      'C or C == 1.7',
     ]

and then a package B which says:

    install_requires = [
       'C or C == 1.7.1',
    ]

which one to pick? C will do, but if we want to be specific, should we pick C 1.7 or C 1.7.1? I propose we let the outer package (A) break the contention and thus decide on C 1.7. The inner package winning would otherwise block framework packages from having the ability to make informed decisions to diverge from recommendations lower down the dependency tree.

Regards,

Martijn

_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to