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