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

[Vinay Sajip]

PJ Eby <pje <at> telecommunity.com> writes:

> Test dependencies allow you to depend on a test framework (e.g. nose) without
> requiring it to be installed at runtime.  Setup dependencies let you depend
> on tools like Pyrex or Cython in order to compile a binary package, without
> requiring them to be available at runtime.

Oh, I understand why the distinctions exist, and they seem reasonable to me.
Sorry I wasn't clear - I meant that I wasn't sure how widely these were used. I
made the comment because I thought that the distinction wasn't preserved in the
new metadata format, but I must have misread - Daniel commented that the
distinction *is* preserved.

> Pkg_resources uses a "greedy" dependency resolver, so it ignores
> circularity as a side-effect.  That is, as soon as the first requirement for
> [explanation snipped]

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?

Regards,

Vinay Sajip