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

[Vinay Sajip]

Daniel Holth <dholth <at> gmail.com> writes:

> David, did you mention a paper about advanced dependency resolution
> algorithms?I don't know how dependency resolution should work. I only claim
> that the very popular distribute needs to provide setuptools to work; right now
> it does that with a hack by including a setuptools .egg-info directory.

Do you mean pip? distribute is an incarnation of setuptools, after all.

> I don't expect provides-dist to be a very widely used feature at all.As for
> Provides-Dist you should just index that field locally and the remote package
> index should let you search by provides instead of by the package name (in
> that index the package name is one of the provides values). You are searching
> the entire metadata, it's just already indexed so it's efficient.

So if several different distributions on PyPI say that they "provide"
"Foo (1.0)", which one are you supposed to pick? The question of efficiency
isn't the main concern here - it's "what do you do with the (no doubt
efficiently-returned) results?"

> In Python/pypi, which is mostly libraries and not applications like in Debian,
> a fork would be the normal use case for provides-dist. If the plugin systems
> were more widely used then you might have more non-fork provides-dist lines,
> for example if trac required at least one revision control backend.

Linux distros, Debian included, ship lots of libraries too. I get most of the
commonly-used libraries (like setuptools, PIL) through the distro package
manager.

Forks don't need a *multi-valued* Provides field. And ISTM in the comment about
Trac, you are referring to what pip calls bundles - which, IIUC, is a
deprecated feature of pip. With a good repository infrastructure and packaging
tools, I'm not sure why bundles would be needed.

Often, packages which bundle other packages don't advertise those other
packages as being provided (and rightly so, in my view). For example, Django
includes simplejson, six etc. but that doesn't need to be exposed at the
PyPI level. It can be considered as implementation detail. The bundled packages
could even diverge from their non-bundled counterparts to better serve the
needs of the "main" package.

Regards,

Vinay Sajip