<div class="gmail_quote">On Sat, Nov 10, 2012 at 6:51 AM, Vinay Sajip <span dir="ltr"><<a href="mailto:vinay_sajip@yahoo.co.uk" target="_blank">vinay_sajip@yahoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Carl Meyer <carl <at> <a href="http://oddbird.net" target="_blank">oddbird.net</a>> writes:<br>
<br>
> already satisfied. In pip this happens here:<br>
> <a href="https://github.com/pypa/pip/blob/develop/pip/req.py#L1091" target="_blank">https://github.com/pypa/pip/blob/develop/pip/req.py#L1091</a><br>
><br>
> More generally, I wouldn't really recommend pip's dependency resolution<br>
> logic as a model for new Python code in this area. There are some not<br>
> uncommon cases that it handles poorly; see<br>
> <a href="https://github.com/pypa/pip/issues/174" target="_blank">https://github.com/pypa/pip/issues/174</a> and<br>
> <a href="http://bugs.python.org/issue8927" target="_blank">http://bugs.python.org/issue8927</a>. (To be fair to pip, these cases aren't<br>
> trivial when you have to download and unpack an sdist before you can<br>
<br>
</div>Thanks for the pointers.<br>
<div class="im"><br>
> find out anything about its dependencies, but I'd hope that with the new<br>
> metadata PEPs Python packaging code could get a bit smarter in this area.)<br>
<br>
</div>AFAICT, the proposed metadata PEP changes don't offer the same requirement<br>
granularity as setuptools / distribute (for example, 'Requires-Dist' as against<br>
'install_requires', 'setup_requires', 'test_requires').<br>
<br>
Anyway, I'll take a look at the issue you mentioned and see how the dependency<br>
code in distlib stacks up. Currently, it keeps the requirements distinct for<br>
'install', 'setup' and 'test'. The distinctions seem reasonable in theory,<br>
though I'm not sure how useful they are in practice.<br></blockquote><div><br>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.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the case I was quoting, the circular dependency wasn't being treated as any<br>
kind of conflict - I just came across cycles when testing topological sorting of<br>
dependency graphs, and was curious about them.<br></blockquote><div><br>Pkg_resources uses a "greedy" dependency resolver, so it ignores circularity as a side-effect.  That is, as soon as the first requirement for a project is found, a suitable version is grabbed and added to the tentative new path.  Thus, if another reference to the same project occurs elsewhere, the project has already been added to the path, so the dependency is already satisfied and does not recurse.<br>
<br>Btw, there are other tricky corner cases for dependency resolution; with distribute and sufficiently-old version of setuptools, circular setup-time dependencies can lead to recursion, unless the circular package is available in binary form.  This was fixed a few years ago in setuptools by ensuring that nested source build invocations saved and restored pkg_resources state, or something like that, but I don't think distribute ever integrated those changes.<br>
<br>In any case, that's more of a practical issue for build tools than a dependency resolver issue per se.<br><br>Btw, I did consider using a backtracking dependency resolver in pkg_resources -- i.e. one that could handle the sort of conflicts linked above -- but decided against it on the basis that <br>
<br>1. Backtracking resolution could be exponential time in worst-case scenarios, and<br>2. Dependency information wasn't available from PyPI without actually downloading and building things anyway, so there were limits to how much the backtracking would help.<br>
<br></div></div>