Packages and Crates
The first parts of the module system we’ll cover are packages and crates. A crate is a binary or library. The crate root is a source file that the Rust compiler starts from and makes up the root module of your crate (we’ll explain modules in depth in the “Defining Modules to Control Scope and Privacy”) section. A package is one or more crates that provide a set of functionality. A package contains a Cargo.toml file that describes how to build those crates.
Several rules determine what a package can contain. A package must contain zero or one library crates, and no more. It can contain as many binary crates as you’d like, but it must contain at least one crate (either library or binary).
Let’s walk through what happens when we create a package. First, we enter the
command cargo new
:
$ cargo new my-project
Created binary (application) `my-project` package
$ ls my-project
Cargo.toml
src
$ ls my-project/src
main.rs
When we entered the command, Cargo created a Cargo.toml file, giving us a
package. Looking at the contents of Cargo.toml, there’s no mention of
src/main.rs because Cargo follows a convention that src/main.rs is the
crate root of a binary crate with the same name as the package. Likewise, Cargo
knows that if the package directory contains src/lib.rs, the package contains
a library crate with the same name as the package, and src/lib.rs is its
crate root. Cargo passes the crate root files to rustc
to build the library
or binary.
Here, we have a package that only contains src/main.rs, meaning it only
contains a binary crate named my-project
. If a package contains src/main.rs
and src/lib.rs, it has two crates: a library and a binary, both with the same
name as the package. A package can have multiple binary crates by placing files
in the src/bin directory: each file will be a separate binary crate.
A crate will group related functionality together in a scope so the
functionality is easy to share between multiple projects. For example, the
rand
crate we used in Chapter 2 provides functionality that generates random
numbers. We can use that functionality in our own projects by bringing the
rand
crate into our project’s scope. All the functionality provided by the
rand
crate is accessible through the crate’s name, rand
.
Keeping a crate’s functionality in its own scope clarifies whether particular
functionality is defined in our crate or the rand
crate and prevents
potential conflicts. For example, the rand
crate provides a trait named
Rng
. We can also define a struct
named Rng
in our own crate. Because a
crate’s functionality is namespaced in its own scope, when we add rand
as a
dependency, the compiler isn’t confused about what the name Rng
refers to. In
our crate, it refers to the struct Rng
that we defined. We would access the
Rng
trait from the rand
crate as rand::Rng
.
Let’s move on and talk about the module system!