[Distutils] Reverse dependencies

[Martin Aspeli]

Jim Fulton wrote:
> FWIW, I expect to have to implement this for buildout at some point.   
> I don't plan to do it until it becomes a priority. :)

Interesting. :)

> WRT platform, I see this as an anti-solution.  Fortunately, it looks  
> like it has already been dismissed. :)  The reason I see this as an  
> anti-solution is that we already have a platform, namely Python 2.4,  
> that might be better treated as a dependency.  For example, there  
> isn't a way, AFAIK, to state Python version requirements for source  
> releases.  I think it might be cleaner if things like Python version  
> and maybe even size of unicode characters could be handled using the  
> dependency mechanism.

To me, the word "platform" means more than Python version and low-level 
OS things. I also meant things like "Plone" or "Zope". I'm not saying 
these can't be handled by dependency backtracking, but it may be more 
practical to think in terms of some higher level constructs.

For example, if I develop a package for Plone, I may target Plone 3, 
test with Plone 3.0.x and know that it works with 3.0.1.

However, I may not have any direct dependencies on Plone - the package 
could be more general, but other things used in Plone may mean that I 
know it works with 3.0.1 but no earlier versions, and possibly not 4.0+ 
either.

In a perfect world, entirely strict dependencies should tell us all 
this. However, in practice, since things like Plone and Zope are 
released as whole units, and not necessarily managed strictly as a 
system of with eggs requiring each other (which, for something like 
Plone, could end up being quite complex to manage), that may not work. 
The algorithm to find them could be pretty hairy as well.

As the builder of an application on top of Plone, all I really want is 
"the version of the package that works with Plone 3.0.2" (or whichever 
version I'm using). In this case, such "known-good platform" metadata 
may be quite useful.

Martin