cargo-lite is an interim package manager for Rust that is sloppily
designed and implemented, intended to have something that "just works" until
there is a package manager that works reliably and well. This isn't intended
to grow into a production-quality package manager.
What does it do? It fetches dependencies and builds them. It can fetch from git, hg, or local directories. It doesn't do any handling of versions etc. It will rebuild when dependencies change, as well as when rustc's version changes.
You can use pip:
pip install cargo-lite
Or, you can do it manually, using distutils:
git clone https://github.com/cmr/cargo-lite.git cd cargo-lite sudo python setup.py install
You can find me on
cmr. Look for me
Feel free to open issues or send pull requests. Pull requests should be
How To Use
First, you need a
cargo-lite.conf in the top-level directory of your
repository. In it you will list your dependencies. You do this with a nested
deps = [ ["--git", "http://github.com/bjz/gl-rs.git"] , ["--git", "http://github.com/bjz/glfw-rs.git"] ]
This specifies two dependencies: gl-rs and glfw-rs. It specifies that they
should be cloned with
cargo-lite install will read their
cargo-lite.conf, install all of their dependencies, and then
build them, copying their build artifacts into the package depository
(currently hardcoded as
~/.rust/lib). To build your own crate, you need an
additional section in the
[build] crate_root = "src/main.rs"
cargo-lite to run
src/main.rs. It will pass
it the proper
-L to link to its dependencies. You can add an additional
directive to the build section to add flags:
[build] crate_root = "src/main.rs" rustc_args = ["-C", "prefer-dynamic"]
And that's it, for simple crates! You can use
cargo-lite build to build
your crate. It will output the build artifacts in the same place as running
rustc src/main.rs would. For building a library, you need to do:
[build] crate_root = "src/lib.rs" crate_type = "library"
For more complex projects,
cargo-lite accepts the following directives:
subpackages = ["src/foo", "src/examples"] [build] build_cmd = "./build.sh"
cargo-lite.py will first recurse into the subpackages, installing those,
and will then execute the
build_cmd. Two environment variables will be
added, which the
build_cmd is expected to respect:
which is where artifacts to be installed must be copied to, and
CARGO_RUSTFLAGS, which should be passed to rustc for all artifacts that
are to be copied into
CARGO_RUSTFLAGS will include
-L /path/where/cargo-lite/libs/are/stored and optimization
- A list of directories, relative to the directory this
cargo-lite.confis in, to recurse into and install. Note that subpackages installed unconditionally, and cannot fetch their source from a remote source. They provide a way to structure a single repository that has multiple crates in it. Subpackages are processed in order, and before any build instructions in
build section describes how to build a package. If there are defined
subpackages, this is optional. Otherwise, it is required. It has the following
- A string. If specified,
rustcwill be invoked on this file, using the correct arguments (given the
- A string. Either "binary" or "library". Specifies whether the crate is to be built as a library or executable binary. Optional, the default is "binary".
- A list of strings. If specified, these arguments will be passed on to
crate_rootis specified, or joined with a single space and exported in the
CARGO_RUSTFLAGSenvironment variable if
A list of strings. If specified, any files matching any of these globs will be hashed as part of determining whether a package should be rebuilt or not. By default, only
*.rsis considered. Do note that this is, by nature, a quadratic algorithm. Take care not to specify many globs, and specifying the most common globs first. Since, on every build, every file in every dependency is hashed,
mtimeis hashed, to try and keep time down. Due to the crate model, fine-grained dependency tracking isn't particularly useful.
- Either a string, or a list of strings. If just a string, it specifies the program that will carry out the building. If a list, the first argument is the program that will be executed, and the rest the arguments to that program.
At least one of
build_cmd must be specified. If both
are specified, the
build_cmd is run first, allowing for custom code
generation. If neither is specified, processing will halt, and an error will
Because it's simple, ubiquitous, and most importantly, what I know.
Wow, this kinda sucks!
Yup! I don't handle versioning, intelligent rebuilding, or anything of that sort. Pull requests accepted, but keep in mind that this is meant to be temporary, and not solve the hard problems of package management.
- Versioning of dependencies
- Build system beyond simply running rustc or a single shell command
- rustc integration beyond what is already present (no hooking into libsyntax etc)
- rust rewrite, or a rewrite into any other language
- Allow passing arbitrary rustc args