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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
