What's this?

This crate demonstrates a crate-level cyclic dependency in Cargo.

Cargo enforces acyclicity on the feature-level not the crate-level [1], and therefore it is trivially possible to create cyclic dependencies on the crate-level.

This is an instance of the general theorem that when you have a partial order defined on a set B, and a non-injective surjective mapping F from that set to another strictly smaller set S, then an ordering on S defined as

s0 <= s1 iff exists b0 <= b1 where F(b0) = s0 and F(b1) = s1

is not always a partial order, but is a pre-order that may contain cycles.

(This is related to various impossibility results on voting systems.)

Consequences

As applied to package managers:

• B is "the set of crate features" or "the set of binary packages"
• the ordering on B is the feature-level or binary-level dependency ordering
• S is "the set of crates" or "the set of source packages"
• the ordering on S is the crate-level or source-level dependency ordering

Cargo does not use the ordering on S, and therefore these cycles do not have any practical negative consequences on the Rust ecosystem. What cargo does, is use the ordering on B to resolve feature-level dependencies, then translate the chosen elements of B to determine the chosen elements of S - i.e. the crates that need to be downloaded to satisfy feature-level dependencies.

However, naive ways of translating Cargo crates into other package managers may result in the ordering on S being used by the other package manager. This has the following practical negative consequences:

• the other package manager may not support cyclic dependencies on S

• even if it supports cyclic dependencies on S in the general case, in a specific case S may contain crates that conflict with each other. This would not be the case if the ordering on B were used directly, as conflicts on this level are self-policed away by Rust developers; but there is no such self-policing on the level of S.