[Distutils] Reverse dependencies

[Martin Aspeli]

Hi,

I'm finding myself in the following situation.

I'm writing package my.app, which encapsulates higher level concepts 
specific to my application. My application runs on Plone, targeting 
version 3, which runs on Zope 2.10 and sits on top of CMF 2.1.

Now, I want to depend on your.package, which provides some autonomous 
functionality, say support for a particular use case or application policy.

I want to be able to get bugfixes and incremental improvements for 
your.package in the future, and when other people install my.app I'd 
like them to have the latest appropriate version of your.package.

Let's say your.package version 1.5 targets Plone 3 and Zope 2.10. At 
this point I can't know if there'll be a 1.6 or a 1.7 or whatever also 
targeting Plone 3. At some point, maybe version 2.0, maybe 1.8, maybe 
4.5, it's possible that your.package will stop working on Plone 3. At 
this point, someone installing my.app may inadvertently get an 
incompatible version of your.package, if I have a broad (or lazy) 
install_requires.

What I'd like to be able to say, is "I run on Plone 3, CMF 2.1, Zope 
2.10, Python 2.5" -- these are my "framework" realities -- and I'd like 
the latest version of your.package supporting this platform.

For that to work, your.package would need to declare such compatibility. 
If it doesn't, I'd need to research and encode this in my own 
install_requires. I may need to change it in the future, when the 
roadmap for your.package becomes more clear.

The safe choice is possibly to declare a very narrow version 
(>=1.5<1.6), at the risk of losing out on bug fixes.

But is there any support for such declarative "reverse" dependencies? Is 
it something worth exploring further?

Martin