Consolidating cargo dependencies
<p>I have a project that has a dependency (a cookie utility) that has a dependency on <a href="https://github.com/iron/iron/" rel="nofollow noreferrer">iron</a> <code>&gt;= 0.3, &lt;= 0.4</code>.</p>

<p>My project has a dependency on iron <code>0.3</code> (so I can use the <code>router</code> middleware that hasn't yet been updated to the latest iron).</p>

<p>When I try to compile my project, the cookie utility pulls the <code>0.4</code> version of iron, and I get errors since different versions of iron are being used.</p>

<p>However, I can do:</p>

<pre><code>cargo update -p &lt;cookie utility&gt;
</code></pre>

<p>which (usually) changes that package's dependency on iron to match the one I am using, and removes the extraneous dependency on iron <code>0.4</code>. (Bizarrely, I sometimes have to run that command a couple of times before it updates.)</p>

<p>Apparently I can't specify the dependency version of a dependency: <a href="https://stackoverflow.com/questions/27770031/set-specific-version-of-the-dependency-of-a-projects-dependency-in-cargo-toml-o">Set specific version of the dependency of a project&#39;s dependency in Cargo.toml or Cargo.lock</a>.</p>

<p>It would be nice if cargo could guess that I want to use a single version of iron, but I understand why it can't. However, I'm confused about why <code>cargo update -p &lt;package&gt;</code> actually works; it seems non-intuitive that it would update a dependency for the package. </p>

<hr/>

<p>I guess my first real question is: how can I specify the dependency versions of dependencies (when and only when the version I want is within the supported version range of that library)? I don't think the solutions suggested in the question linked above are ideal. I feel like it would be better if Cargo could support this well, so that libraries could leave their dependency version ranges as open as their functionality allows.</p>

<p>At the same time, I found this "trick" that seems to do what I want (<code>cargo update -p &lt;pkg&gt;</code>). I haven't looked super hard, but this behavior doesn't seem to be described in any obvious place. My second question is: is this a valid way to coalesce dependencies? Is there any place I can find more information about this?</p>

<hr/>

<p>And steps to reproduce:</p>

<ol>
<li>Create a new project: <code>cargo new --bin ironapp</code>; <code>cd ironapp</code>.</li>
<li>Create the cookie dependency: <code>cargo new cookie_util</code>.</li>
<li>In <code>cookie_util/Cargo.toml</code> add one dependency: <code>iron = "&gt;= 0.3, &lt;= 0.4"</code>.</li>
<li>In <code>Cargo.toml</code> add two dependencies: <code>iron = "0.3.0"</code> and <code>cookie_util = { path = "cookie_util"}</code>.</li>
<li><code>cargo build</code>. Confirm that two versions of iron are required in <code>Cargo.lock</code>.</li>
<li>Run <code>cargo update -p cookie_util</code> anywhere between 1 and 4 (or more) times. Eventually it will remove the dependency on <code>iron 0.4.0</code>.</li>
</ol>

<p>I just tested this on rustc-1.10.0/cargo-0.11.0. I made sure <code>target</code> and <code>Cargo.lock</code> were both absent at the start of step 1.</p>