[Zope3-dev] pinning eggs: 'or' in version requirements

[Martijn Faassen]

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