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
