On Monday, November 12, 2012 at 6:10 PM, Vinay Sajip wrote:
PJ Eby
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@python.org (mailto:Distutils-SIG@python.org) http://mail.python.org/mailman/listinfo/distutils-sig