<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>This is pretty awesome. I notice that <a href="http://crates.io">http://crates.io</a> doesn’t link to the GitHub repo though. Seems like that might be a useful thing to add.</div><div><br></div><div>-Kevin</div><br><div><blockquote type="cite"><div>On Jun 23, 2014, at 10:50 PM, Yehuda Katz <<a href="mailto:wycats@gmail.com">wycats@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">Folks,<div><br></div><div>I'm happy to announce that Cargo is now ready to try out!</div><div><br></div><div>The Cargo repository is now at <a href="https://github.com/rust-lang/cargo">https://github.com/rust-lang/cargo</a> and you can learn all about it at <a href="http://crates.io/">http://crates.io/</a>. Don't forget to check out the FAQ at <a href="http://crates.io/faq">http://crates.io/faq</a>.<br>

</div><div><br></div><div>You can build Cargo from master using the latest `rustc` and running `make install`. It assumes a `rustc` and `git` on the path, so you won't need to recompile Cargo every time you update the nightly.</div>

<div><br></div><div>Cargo is still under heavy development and features are coming quickly. At the moment, all dependencies are downloaded from Github, but we are working on a Cargo registry that you will be able to publish packages to. There are more details about that in the FAQ.</div>

<div><br></div><div>The next features we're planning on working on are:</div><div><ul><li>`cargo package <name>` to create a new package skeleton</li><li>Supporting refs other than `master` from git packages</li>

<li>Support for environments (such as development, production and test) as well as a `cargo test` command. This includes per-environment dependencies.</li><li>Support for per-platform configuration.</li><li>More deterministic builds using a shrinkwrap file (like the bundler Gemfile.lock or shrinkwrap.json in npm).</li>

</ul><div>Since people have asked often, we plan to transparently support duplicates of the same package name and version in the following conditions:</div></div><div><ul><li>From different git repositories or different branches of the same git repository</li>

<li>In versions less than 1.0 for packages from the Cargo registry</li><li>For different major versions for packages from the Cargo registry</li></ul><div>By default, we will encourage package authors to comply with semantic versioning and not introduce breaking changes in minor versions by using the single highest available minor version for each depended-on major version of a package from the Cargo registry.</div>

</div><div><br></div><div>For example, if I have three packages:</div><div><ul><li>uno depends on json 1.3.6</li><li>dos depends on json 1.4.12</li><li>tres depends on json 2.1.0</li></ul><div>Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres. This makes good use of Rust's symbol mangling support, while also avoiding unnecessary code bloat.</div>

</div><div><br></div><div>This will tend to produce significantly smaller binary sizes than encouraging libraries to depend on precise versions of published packages. We tried to strike a good balance between isolating unstable code and avoiding binary bloat in stable libraries. As the ecosystem grows, we'll watch carefully and see if any tweaks are necessary.</div>

<div><br></div><div><div>Yehuda Katz<br>(ph) 718.877.1325</div>
</div></div>
_______________________________________________<br>Rust-dev mailing list<br><a href="mailto:Rust-dev@mozilla.org">Rust-dev@mozilla.org</a><br>https://mail.mozilla.org/listinfo/rust-dev<br></div></blockquote></div><br></body></html>