[Distutils] (How) do setuptools/distribute/pip handle circular dependencies?

[Donald Stufft]

On Monday, November 12, 2012 at 6:10 PM, Vinay Sajip wrote:
> PJ Eby <pje <at> telecommunity.com (http://telecommunity.com)> writes:
> 
> Thanks for the explanation. It seems to me that the new metadata formats make
> dependency resolution more difficult because they allow for e.g.
> 'Provides-Dist' as a multi-value field. Perhaps I'm misunderstanding, but this,
> it seems to me, opens the door for a project named A on PyPI to provide e.g.
> "A (1.0)", "B (1.5)" and "C (2.0)", and likewise, projects B and C on PyPI
> could provide slightly different versions of "A", "B" and "C". You can soon get
> a rat's nest of dependencies in the resolver - and if you get something like
> the case that Carl linked to, where some element of backtracking might be in
> order, it doesn't seem computationally straightforward to resolve dependencies,
> perhaps even with a SAT solver in the mix. Is this a case of practicality
> losing out to purity? Assuming it's easy to pull any version from an index, I
> can't see a compelling case for any distribution archive for A to ever provide
> anything other than e.g. "A (x.y)". Can someone point me to the real need for
> multi-valued "Provides" fields? Or have I completely misunderstood this aspect
> of the metadata?
> 
> 

I think Provides is a misfeature as well. Even RPM, debs, etc which do have a
provides feature do not use it as it is used here. They allow you to use it for
a virtual package (e.g. email) which any number of packages could provide
but it's not there to allow one package to masquerade as another. 
> 
> Regards,
> 
> Vinay Sajip
> 
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org (mailto:Distutils-SIG at python.org)
> http://mail.python.org/mailman/listinfo/distutils-sig
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20121112/7011b65d/attachment-0001.html>