Michael Hoffman wrote:
Martijn Faassen wrote:
Hi there,
Currently setup.py allows install_requires to specify the dependencies, possibly including exact version numbers of a package.
It is however beneficial to only specify the *minimum* of expected requirements in there, to retain maximum flexibility of use. This means you'd typically say:
install_requires = [ 'foo', 'bar >= 1.3', ]
if you know you need some version of foo, and at least version 1.3 of your package. This allows developers who use your package to choose themselves which version of foo and bar they want to use, without getting version conflicts as long as you stay within the stated constraints.
Can't you use the extras_require feature for this?
It is my understanding that extra_requires is used to express *extra*, optional requirements beyond those in install_requires. That's not at all what I'm trying to talk about, so my apologies for being so unclear. install_recommends as I proposed it would be used to offer recommendations for the core requirements (or, I guess, also recommendations of versions for the extra requirements if desired). So, the exact same requirements are expressed, just with an additional tightening of version numbers. I understand how the name "install_recommends" could be confusing terminology given the way package managers use the term 'recommended packages', which means extra that you could install too to get more features. "install_prefers" instead? An alternative would be to expand the syntax of install_requires and extra_require to allow the recommended version number hint. Something like this: install_requires = [ 'foo (1.2.1)', 'bar >= 1.3 (1.3.2)', ] Installation tools are free to ignore the latter number and just install something that fits the basic requirement: install_requires = [ 'foo', 'bar >= 1.3', ] But an installation could be taught to take this into account and get those versions, and do the equivalent of this: install_requires = [ 'foo == 1.2.1', 'bar == 1.3.2', ] The install tool could choose in the case of conflicting version numbers to pick the one in the outer packages. So, if foo depends on bar, and bar says it would prefer qux 1.3, while foo actually prefers 1.3.2, foo would trump bar. Again, all this would be entirely optional behavior of the installation tool. I'm just asking for a way to express this information in the package metadata at all, so that install tools could be taught to use it. Regards, Martijn