Folks,
I'm happy to announce that Cargo is now ready to try out!
The Cargo repository is now at https://github.com/rust-lang/cargo and you
can learn all about it at http://crates.io/. Don't forget to check out the
FAQ at http://crates.io/faq.
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.
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.
The next features we're planning on working on are:
- `cargo package <name>` to create a new package skeleton
- Supporting refs other than `master` from git packages
- Support for environments (such as development, production and test) as
well as a `cargo test` command. This includes per-environment dependencies.
- Support for per-platform configuration.
- More deterministic builds using a shrinkwrap file (like the bundler
Gemfile.lock or shrinkwrap.json in npm).
Since people have asked often, we plan to transparently support duplicates
of the same package name and version in the following conditions:
- From different git repositories or different branches of the same git
repository
- In versions less than 1.0 for packages from the Cargo registry
- For different major versions for packages from the Cargo registry
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.
For example, if I have three packages:
- uno depends on json 1.3.6
- dos depends on json 1.4.12
- tres depends on json 2.1.0
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.
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.
Yehuda Katz
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140623/9325634c/attachment.html>