2022-01-18 22:40:27 +00:00
|
|
|
|
<!-- DO NOT EDIT THIS FILE.
|
|
|
|
|
|
|
|
|
|
This file is periodically generated from the content in the `/src/`
|
|
|
|
|
directory, so all fixes need to be made in `/src/`.
|
|
|
|
|
-->
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
[TOC]
|
|
|
|
|
|
|
|
|
|
# More About Cargo and Crates.io
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
So far, we’ve used only the most basic features of Cargo to build, run, and
|
|
|
|
|
test our code, but it can do a lot more. In this chapter, we’ll discuss some of
|
|
|
|
|
its other, more advanced features to show you how to do the following:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
* Customize your build through release profiles.
|
2022-08-23 23:42:31 +00:00
|
|
|
|
* Publish libraries on *https://crates.i**o*.
|
2022-08-23 14:33:45 +00:00
|
|
|
|
* Organize large projects with workspaces.
|
2022-08-23 23:42:31 +00:00
|
|
|
|
* Install binaries from *https://crates.io*.
|
2022-08-23 14:33:45 +00:00
|
|
|
|
* Extend Cargo using custom commands.
|
2022-09-13 16:54:09 +00:00
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Cargo can do even more than the functionality we cover in this chapter, so for
|
|
|
|
|
a full explanation of all its features, see its documentation at
|
2022-08-23 14:33:45 +00:00
|
|
|
|
*https://doc.rust-lang.org/cargo*.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
## Customizing Builds with Release Profiles
|
|
|
|
|
|
|
|
|
|
In Rust, *release profiles* are predefined and customizable profiles with
|
|
|
|
|
different configurations that allow a programmer to have more control over
|
|
|
|
|
various options for compiling code. Each profile is configured independently of
|
|
|
|
|
the others.
|
|
|
|
|
|
|
|
|
|
Cargo has two main profiles: the `dev` profile Cargo uses when you run `cargo
|
2022-08-24 13:12:29 +00:00
|
|
|
|
build`, and the `release` profile Cargo uses when you run `cargo build
|
2022-01-08 02:37:05 +00:00
|
|
|
|
--release`. The `dev` profile is defined with good defaults for development,
|
|
|
|
|
and the `release` profile has good defaults for release builds.
|
|
|
|
|
|
|
|
|
|
These profile names might be familiar from the output of your builds:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo build
|
|
|
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.0s
|
|
|
|
|
$ cargo build --release
|
|
|
|
|
Finished release [optimized] target(s) in 0.0s
|
|
|
|
|
```
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
The `dev` and `release` are these different profiles used by the compiler.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
Cargo has default settings for each of the profiles that apply when you haven’t
|
2022-04-29 12:55:43 +00:00
|
|
|
|
explicitly added any `[profile.*]` sections in the project’s *Cargo.toml* file.
|
|
|
|
|
By adding `[profile.*]` sections for any profile you want to customize, you
|
|
|
|
|
override any subset of the default settings. For example, here are the default
|
|
|
|
|
values for the `opt-level` setting for the `dev` and `release` profiles:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[profile.dev]
|
|
|
|
|
opt-level = 0
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
[profile.release]
|
|
|
|
|
opt-level = 3
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The `opt-level` setting controls the number of optimizations Rust will apply to
|
|
|
|
|
your code, with a range of 0 to 3. Applying more optimizations extends
|
|
|
|
|
compiling time, so if you’re in development and compiling your code often,
|
2022-08-23 14:33:45 +00:00
|
|
|
|
you’ll want fewer optimizations to compile faster even if the resultant code
|
2022-04-29 12:55:43 +00:00
|
|
|
|
runs slower. The default `opt-level` for `dev` is therefore `0`. When you’re
|
|
|
|
|
ready to release your code, it’s best to spend more time compiling. You’ll only
|
|
|
|
|
compile in release mode once, but you’ll run the compiled program many times,
|
|
|
|
|
so release mode trades longer compile time for code that runs faster. That is
|
|
|
|
|
why the default `opt-level` for the `release` profile is `3`.
|
|
|
|
|
|
|
|
|
|
You can override a default setting by adding a different value for it in
|
2022-01-08 02:37:05 +00:00
|
|
|
|
*Cargo.toml*. For example, if we want to use optimization level 1 in the
|
|
|
|
|
development profile, we can add these two lines to our project’s *Cargo.toml*
|
|
|
|
|
file:
|
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[profile.dev]
|
|
|
|
|
opt-level = 1
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This code overrides the default setting of `0`. Now when we run `cargo build`,
|
|
|
|
|
Cargo will use the defaults for the `dev` profile plus our customization to
|
|
|
|
|
`opt-level`. Because we set `opt-level` to `1`, Cargo will apply more
|
|
|
|
|
optimizations than the default, but not as many as in a release build.
|
|
|
|
|
|
|
|
|
|
For the full list of configuration options and defaults for each profile, see
|
2022-08-23 14:33:45 +00:00
|
|
|
|
Cargo’s documentation at
|
|
|
|
|
*https://doc.rust-lang.org/cargo/reference/profiles.html*.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
## Publishing a Crate to Crates.io
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
We’ve used packages from *https://crates.io* as dependencies of our project,
|
|
|
|
|
but you can also share your code with other people by publishing your own
|
|
|
|
|
packages. The crate registry at *https://crates.io* distributes the source code
|
|
|
|
|
of your packages, so it primarily hosts code that is open source.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Rust and Cargo have features that make your published package easier for people
|
|
|
|
|
to find and use. We’ll talk about some of these features next and then explain
|
|
|
|
|
how to publish a package.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
### Making Useful Documentation Comments
|
|
|
|
|
|
|
|
|
|
Accurately documenting your packages will help other users know how and when to
|
|
|
|
|
use them, so it’s worth investing the time to write documentation. In Chapter
|
|
|
|
|
3, we discussed how to comment Rust code using two slashes, `//`. Rust also has
|
|
|
|
|
a particular kind of comment for documentation, known conveniently as a
|
|
|
|
|
*documentation comment*, that will generate HTML documentation. The HTML
|
|
|
|
|
displays the contents of documentation comments for public API items intended
|
|
|
|
|
for programmers interested in knowing how to *use* your crate as opposed to how
|
|
|
|
|
your crate is *implemented*.
|
|
|
|
|
|
|
|
|
|
Documentation comments use three slashes, `///`, instead of two and support
|
|
|
|
|
Markdown notation for formatting the text. Place documentation comments just
|
|
|
|
|
before the item they’re documenting. Listing 14-1 shows documentation comments
|
|
|
|
|
for an `add_one` function in a crate named `my_crate`.
|
|
|
|
|
|
|
|
|
|
Filename: src/lib.rs
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
```
|
2022-01-08 02:37:05 +00:00
|
|
|
|
/// Adds one to the number given.
|
|
|
|
|
///
|
|
|
|
|
/// # Examples
|
|
|
|
|
///
|
2022-06-04 13:42:18 +00:00
|
|
|
|
/// ```
|
2022-01-08 02:37:05 +00:00
|
|
|
|
/// let arg = 5;
|
|
|
|
|
/// let answer = my_crate::add_one(arg);
|
|
|
|
|
///
|
|
|
|
|
/// assert_eq!(6, answer);
|
2022-06-04 13:42:18 +00:00
|
|
|
|
/// ```
|
2022-01-08 02:37:05 +00:00
|
|
|
|
pub fn add_one(x: i32) -> i32 {
|
|
|
|
|
x + 1
|
|
|
|
|
}
|
2022-08-23 14:33:45 +00:00
|
|
|
|
```
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-1: A documentation comment for a function
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Here, we give a description of what the `add_one` function does, start a
|
|
|
|
|
section with the heading `Examples`, and then provide code that demonstrates
|
|
|
|
|
how to use the `add_one` function. We can generate the HTML documentation from
|
|
|
|
|
this documentation comment by running `cargo doc`. This command runs the
|
|
|
|
|
`rustdoc` tool distributed with Rust and puts the generated HTML documentation
|
|
|
|
|
in the *target/doc* directory.
|
|
|
|
|
|
|
|
|
|
For convenience, running `cargo doc --open` will build the HTML for your
|
|
|
|
|
current crate’s documentation (as well as the documentation for all of your
|
|
|
|
|
crate’s dependencies) and open the result in a web browser. Navigate to the
|
|
|
|
|
`add_one` function and you’ll see how the text in the documentation comments is
|
2022-08-23 14:33:45 +00:00
|
|
|
|
rendered, as shown in Figure 14-1.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Figure 14-1: HTML documentation for the `add_one` function
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
#### Commonly Used Sections
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
We used the `# Examples` Markdown heading in Listing 14-1 to create a section
|
|
|
|
|
in the HTML with the title “Examples.” Here are some other sections that crate
|
|
|
|
|
authors commonly use in their documentation:
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
* **Panics**: The scenarios in which the function being documented could panic.
|
|
|
|
|
Callers of the function who don’t want their programs to panic should make sure
|
|
|
|
|
they don’t call the function in these situations.
|
|
|
|
|
* **Errors**: If the function returns a `Result`, describing the kinds of
|
|
|
|
|
errors that might occur and what conditions might cause those errors to be
|
|
|
|
|
returned can be helpful to callers so they can write code to handle the
|
|
|
|
|
different kinds of errors in different ways.
|
|
|
|
|
* **Safety**: If the function is `unsafe` to call (we discuss unsafety in
|
|
|
|
|
Chapter 19), there should be a section explaining why the function is unsafe
|
|
|
|
|
and covering the invariants that the function expects callers to uphold.
|
|
|
|
|
|
|
|
|
|
Most documentation comments don’t need all of these sections, but this is a
|
|
|
|
|
good checklist to remind you of the aspects of your code users will be
|
2022-04-29 12:55:43 +00:00
|
|
|
|
interested in knowing about.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
#### Documentation Comments as Tests
|
|
|
|
|
|
|
|
|
|
Adding example code blocks in your documentation comments can help demonstrate
|
|
|
|
|
how to use your library, and doing so has an additional bonus: running `cargo
|
|
|
|
|
test` will run the code examples in your documentation as tests! Nothing is
|
|
|
|
|
better than documentation with examples. But nothing is worse than examples
|
|
|
|
|
that don’t work because the code has changed since the documentation was
|
|
|
|
|
written. If we run `cargo test` with the documentation for the `add_one`
|
2022-08-23 14:33:45 +00:00
|
|
|
|
function from Listing 14-1, we will see a section in the test results that
|
|
|
|
|
looks like this:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
Doc-tests my_crate
|
|
|
|
|
|
|
|
|
|
running 1 test
|
|
|
|
|
test src/lib.rs - add_one (line 5) ... ok
|
|
|
|
|
|
2022-08-23 23:42:31 +00:00
|
|
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0
|
|
|
|
|
filtered out; finished in 0.27s
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
2022-08-24 13:12:29 +00:00
|
|
|
|
Now, if we change either the function or the example so the `assert_eq!` in the
|
2022-01-08 02:37:05 +00:00
|
|
|
|
example panics and run `cargo test` again, we’ll see that the doc tests catch
|
|
|
|
|
that the example and the code are out of sync with each other!
|
|
|
|
|
|
|
|
|
|
#### Commenting Contained Items
|
|
|
|
|
|
2022-08-23 23:42:31 +00:00
|
|
|
|
The doc comment `//!` adds documentation to the item that *contains* the
|
|
|
|
|
comments rather than to the items *following* the comments. We typically use
|
2022-04-29 12:55:43 +00:00
|
|
|
|
these doc comments inside the crate root file (*src/lib.rs* by convention) or
|
|
|
|
|
inside a module to document the crate or the module as a whole.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
For example, to add documentation that describes the purpose of the `my_crate`
|
|
|
|
|
crate that contains the `add_one` function, we add documentation comments that
|
|
|
|
|
start with `//!` to the beginning of the *src/lib.rs* file, as shown in Listing
|
2022-08-23 14:33:45 +00:00
|
|
|
|
14-2.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: src/lib.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
//! # My Crate
|
|
|
|
|
//!
|
2022-08-23 23:42:31 +00:00
|
|
|
|
//! `my_crate` is a collection of utilities to make performing
|
|
|
|
|
//! certain calculations more convenient.
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
/// Adds one to the number given.
|
2022-08-23 23:42:31 +00:00
|
|
|
|
--snip--
|
2022-08-23 14:33:45 +00:00
|
|
|
|
```
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-2: Documentation for the `my_crate` crate as a whole
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Notice there isn’t any code after the last line that begins with `//!`. Because
|
|
|
|
|
we started the comments with `//!` instead of `///`, we’re documenting the item
|
|
|
|
|
that contains this comment rather than an item that follows this comment. In
|
2022-04-29 12:55:43 +00:00
|
|
|
|
this case, that item is the *src/lib.rs* file, which is the crate root. These
|
|
|
|
|
comments describe the entire crate.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
When we run `cargo doc --open`, these comments will display on the front page
|
|
|
|
|
of the documentation for `my_crate` above the list of public items in the
|
|
|
|
|
crate, as shown in Figure 14-2.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Figure 14-2: Rendered documentation for `my_crate`, including the comment
|
|
|
|
|
describing the crate as a whole
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Documentation comments within items are useful for describing crates and
|
2022-01-08 02:37:05 +00:00
|
|
|
|
modules especially. Use them to explain the overall purpose of the container to
|
|
|
|
|
help your users understand the crate’s organization.
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
### Exporting a Convenient Public API with pub use
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
The structure of your public API is a major consideration when publishing a
|
|
|
|
|
crate. People who use your crate are less familiar with the structure than you
|
|
|
|
|
are and might have difficulty finding the pieces they want to use if your crate
|
|
|
|
|
has a large module hierarchy.
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
In Chapter 7, we covered how to make items public using the `pub` keyword, and
|
2022-08-24 13:12:29 +00:00
|
|
|
|
how to bring items into a scope with the `use` keyword. However, the structure
|
|
|
|
|
that makes sense to you while you’re developing a crate might not be very
|
|
|
|
|
convenient for your users. You might want to organize your structs in a
|
|
|
|
|
hierarchy containing multiple levels, but then people who want to use a type
|
|
|
|
|
you’ve defined deep in the hierarchy might have trouble finding out that type
|
|
|
|
|
exists. They might also be annoyed at having to enter `use`
|
2022-09-13 16:54:09 +00:00
|
|
|
|
`my_crate::`some_module`::`another_module`::`UsefulType`;` rather than `use`
|
|
|
|
|
`my_crate::`UsefulType`;`.
|
2022-04-29 12:55:43 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
The good news is that if the structure *isn’t* convenient for others to use
|
|
|
|
|
from another library, you don’t have to rearrange your internal organization:
|
|
|
|
|
instead, you can re-export items to make a public structure that’s different
|
2022-08-24 13:12:29 +00:00
|
|
|
|
from your private structure by using `pub use`. *Re-exporting* takes a public
|
2022-01-08 02:37:05 +00:00
|
|
|
|
item in one location and makes it public in another location, as if it were
|
|
|
|
|
defined in the other location instead.
|
|
|
|
|
|
|
|
|
|
For example, say we made a library named `art` for modeling artistic concepts.
|
|
|
|
|
Within this library are two modules: a `kinds` module containing two enums
|
|
|
|
|
named `PrimaryColor` and `SecondaryColor` and a `utils` module containing a
|
2022-08-23 14:33:45 +00:00
|
|
|
|
function named `mix`, as shown in Listing 14-3.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: src/lib.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
//! # Art
|
|
|
|
|
//!
|
|
|
|
|
//! A library for modeling artistic concepts.
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
pub mod kinds {
|
|
|
|
|
/// The primary colors according to the RYB color model.
|
|
|
|
|
pub enum PrimaryColor {
|
|
|
|
|
Red,
|
|
|
|
|
Yellow,
|
|
|
|
|
Blue,
|
|
|
|
|
}
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
/// The secondary colors according to the RYB color model.
|
|
|
|
|
pub enum SecondaryColor {
|
|
|
|
|
Orange,
|
|
|
|
|
Green,
|
|
|
|
|
Purple,
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
pub mod utils {
|
|
|
|
|
use crate::kinds::*;
|
|
|
|
|
|
|
|
|
|
/// Combines two primary colors in equal amounts to create
|
|
|
|
|
/// a secondary color.
|
2022-08-23 23:42:31 +00:00
|
|
|
|
pub fn mix(
|
|
|
|
|
c1: PrimaryColor,
|
|
|
|
|
c2: PrimaryColor,
|
|
|
|
|
) -> SecondaryColor {
|
|
|
|
|
--snip--
|
2022-01-08 02:37:05 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-3: An `art` library with items organized into `kinds` and `utils`
|
|
|
|
|
modules
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Figure 14-3 shows what the front page of the documentation for this crate
|
2022-08-23 14:33:45 +00:00
|
|
|
|
generated by `cargo doc` would look like.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Figure 14-3: Front page of the documentation for `art` that lists the `kinds`
|
|
|
|
|
and `utils` modules
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Note that the `PrimaryColor` and `SecondaryColor` types aren’t listed on the
|
|
|
|
|
front page, nor is the `mix` function. We have to click `kinds` and `utils` to
|
|
|
|
|
see them.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Another crate that depends on this library would need `use` statements that
|
|
|
|
|
bring the items from `art` into scope, specifying the module structure that’s
|
|
|
|
|
currently defined. Listing 14-4 shows an example of a crate that uses the
|
2022-08-23 14:33:45 +00:00
|
|
|
|
`PrimaryColor` and `mix` items from the `art` crate.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: src/main.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
use art::kinds::PrimaryColor;
|
|
|
|
|
use art::utils::mix;
|
|
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
|
let red = PrimaryColor::Red;
|
|
|
|
|
let yellow = PrimaryColor::Yellow;
|
|
|
|
|
mix(red, yellow);
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-4: A crate using the `art` crate’s items with its internal structure
|
|
|
|
|
exported
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
The author of the code in Listing 14-4, which uses the `art` crate, had to
|
|
|
|
|
figure out that `PrimaryColor` is in the `kinds` module and `mix` is in the
|
|
|
|
|
`utils` module. The module structure of the `art` crate is more relevant to
|
2022-04-29 12:55:43 +00:00
|
|
|
|
developers working on the `art` crate than to those using it. The internal
|
|
|
|
|
structure doesn’t contain any useful information for someone trying to
|
|
|
|
|
understand how to use the `art` crate, but rather causes confusion because
|
|
|
|
|
developers who use it have to figure out where to look, and must specify the
|
|
|
|
|
module names in the `use` statements.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
To remove the internal organization from the public API, we can modify the
|
|
|
|
|
`art` crate code in Listing 14-3 to add `pub use` statements to re-export the
|
2022-08-23 14:33:45 +00:00
|
|
|
|
items at the top level, as shown in Listing 14-5.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: src/lib.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
//! # Art
|
|
|
|
|
//!
|
|
|
|
|
//! A library for modeling artistic concepts.
|
|
|
|
|
|
|
|
|
|
pub use self::kinds::PrimaryColor;
|
|
|
|
|
pub use self::kinds::SecondaryColor;
|
|
|
|
|
pub use self::utils::mix;
|
|
|
|
|
|
|
|
|
|
pub mod kinds {
|
2022-08-23 23:42:31 +00:00
|
|
|
|
--snip--
|
2022-01-08 02:37:05 +00:00
|
|
|
|
}
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
pub mod utils {
|
|
|
|
|
--snip--
|
|
|
|
|
}
|
2022-08-23 14:33:45 +00:00
|
|
|
|
```
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-5: Adding `pub use` statements to re-export items
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
The API documentation that `cargo doc` generates for this crate will now list
|
|
|
|
|
and link re-exports on the front page, as shown in Figure 14-4, making the
|
|
|
|
|
`PrimaryColor` and `SecondaryColor` types and the `mix` function easier to find.
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Figure 14-4: The front page of the documentation for `art` that lists the
|
|
|
|
|
re-exports
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
The `art` crate users can still see and use the internal structure from Listing
|
|
|
|
|
14-3 as demonstrated in Listing 14-4, or they can use the more convenient
|
|
|
|
|
structure in Listing 14-5, as shown in Listing 14-6.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: src/main.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
use art::mix;
|
|
|
|
|
use art::PrimaryColor;
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
fn main() {
|
2022-08-23 23:42:31 +00:00
|
|
|
|
--snip--
|
2022-08-23 14:33:45 +00:00
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-6: A program using the re-exported items from the `art` crate
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
|
|
|
|
In cases where there are many nested modules, re-exporting the types at the top
|
2022-01-08 02:37:05 +00:00
|
|
|
|
level with `pub use` can make a significant difference in the experience of
|
2022-06-04 13:42:18 +00:00
|
|
|
|
people who use the crate. Another common use of `pub use` is to re-export
|
2022-08-23 14:33:45 +00:00
|
|
|
|
definitions of a dependency in the current crate to make that crate’s
|
2022-06-04 13:42:18 +00:00
|
|
|
|
definitions part of your crate’s public API.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Creating a useful public API structure is more of an art than a science, and
|
|
|
|
|
you can iterate to find the API that works best for your users. Choosing `pub
|
|
|
|
|
use` gives you flexibility in how you structure your crate internally and
|
|
|
|
|
decouples that internal structure from what you present to your users. Look at
|
|
|
|
|
some of the code of crates you’ve installed to see if their internal structure
|
|
|
|
|
differs from their public API.
|
|
|
|
|
|
|
|
|
|
### Setting Up a Crates.io Account
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
Before you can publish any crates, you need to create an account on
|
|
|
|
|
*https://crates.io* and get an API token. To do so, visit the home page at
|
|
|
|
|
*https://crates.io* and log in via a GitHub account. (The GitHub account is
|
|
|
|
|
currently a requirement, but the site might support other ways of creating an
|
|
|
|
|
account in the future.) Once you’re logged in, visit your account settings at
|
2022-09-13 16:54:09 +00:00
|
|
|
|
*https://crates.io/me* and retrieve your API key. Then run the `cargo login`
|
2022-08-23 14:33:45 +00:00
|
|
|
|
command with your API key, like this:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo login abcdefghijklmnopqrstuvwxyz012345
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This command will inform Cargo of your API token and store it locally in
|
|
|
|
|
*~/.cargo/credentials*. Note that this token is a *secret*: do not share it
|
|
|
|
|
with anyone else. If you do share it with anyone for any reason, you should
|
2022-08-23 14:33:45 +00:00
|
|
|
|
revoke it and generate a new token on *https://crates.io*.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
### Adding Metadata to a New Crate
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Let’s say you have a crate you want to publish. Before publishing, you’ll need
|
|
|
|
|
to add some metadata in the `[package]` section of the crate’s *Cargo.toml*
|
|
|
|
|
file.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Your crate will need a unique name. While you’re working on a crate locally,
|
2022-08-23 14:33:45 +00:00
|
|
|
|
you can name a crate whatever you’d like. However, crate names on
|
|
|
|
|
*https://crates.io* are allocated on a first-come, first-served basis. Once a
|
|
|
|
|
crate name is taken, no one else can publish a crate with that name. Before
|
|
|
|
|
attempting to publish a crate, search for the name you want to use. If the name
|
|
|
|
|
has been used, you will need to find another name and edit the `name` field in
|
|
|
|
|
the *Cargo.toml* file under the `[package]` section to use the new name for
|
|
|
|
|
publishing, like so:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[package]
|
|
|
|
|
name = "guessing_game"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Even if you’ve chosen a unique name, when you run `cargo publish` to publish
|
|
|
|
|
the crate at this point, you’ll get a warning and then an error:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo publish
|
|
|
|
|
Updating crates.io index
|
2022-08-23 23:42:31 +00:00
|
|
|
|
warning: manifest has no description, license, license-file, documentation,
|
|
|
|
|
homepage or repository.
|
2022-08-23 14:33:45 +00:00
|
|
|
|
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata
|
|
|
|
|
for more info.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
--snip--
|
|
|
|
|
error: failed to publish to registry at https://crates.io
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
Caused by:
|
2022-08-23 14:33:45 +00:00
|
|
|
|
the remote server responded with an error: missing or empty metadata fields:
|
2022-08-23 23:42:31 +00:00
|
|
|
|
description, license. Please see https://doc.rust-
|
|
|
|
|
lang.org/cargo/reference/manifest.html for how to upload metadata
|
2022-08-23 14:33:45 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This results in an error because you’re missing some crucial information: a
|
|
|
|
|
description and license are required so people will know what your crate does
|
|
|
|
|
and under what terms they can use it. In *Cargo.toml*, add a description that’s
|
|
|
|
|
just a sentence or two, because it will appear with your crate in search
|
|
|
|
|
results. For the `license` field, you need to give a *license identifier
|
|
|
|
|
value*. The Linux Foundation’s Software Package Data Exchange (SPDX) at
|
|
|
|
|
*http://spdx.org/licenses* lists the identifiers you can use for this value.
|
2022-04-29 12:55:43 +00:00
|
|
|
|
For example, to specify that you’ve licensed your crate using the MIT License,
|
|
|
|
|
add the `MIT` identifier:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[package]
|
|
|
|
|
name = "guessing_game"
|
|
|
|
|
license = "MIT"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
If you want to use a license that doesn’t appear in the SPDX, you need to place
|
|
|
|
|
the text of that license in a file, include the file in your project, and then
|
|
|
|
|
use `license-file` to specify the name of that file instead of using the
|
|
|
|
|
`license` key.
|
|
|
|
|
|
|
|
|
|
Guidance on which license is appropriate for your project is beyond the scope
|
|
|
|
|
of this book. Many people in the Rust community license their projects in the
|
|
|
|
|
same way as Rust by using a dual license of `MIT OR Apache-2.0`. This practice
|
|
|
|
|
demonstrates that you can also specify multiple license identifiers separated
|
|
|
|
|
by `OR` to have multiple licenses for your project.
|
|
|
|
|
|
|
|
|
|
With a unique name, the version, your description, and a license added, the
|
|
|
|
|
*Cargo.toml* file for a project that is ready to publish might look like this:
|
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[package]
|
|
|
|
|
name = "guessing_game"
|
|
|
|
|
version = "0.1.0"
|
|
|
|
|
edition = "2021"
|
2022-08-23 23:42:31 +00:00
|
|
|
|
description = "A fun game where you guess what number the
|
|
|
|
|
computer has chosen."
|
2022-01-08 02:37:05 +00:00
|
|
|
|
license = "MIT OR Apache-2.0"
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
[dependencies]
|
|
|
|
|
```
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
Cargo’s documentation at *https://doc.rust-lang.org/cargo* describes other
|
|
|
|
|
metadata you can specify to ensure that others can discover and use your crate
|
|
|
|
|
more easily.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
### Publishing to Crates.io
|
|
|
|
|
|
|
|
|
|
Now that you’ve created an account, saved your API token, chosen a name for
|
|
|
|
|
your crate, and specified the required metadata, you’re ready to publish!
|
2022-08-23 14:33:45 +00:00
|
|
|
|
Publishing a crate uploads a specific version to *https://crates.io* for others
|
|
|
|
|
to use.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Be careful, because a publish is *permanent*. The version can never be
|
2022-08-23 23:42:31 +00:00
|
|
|
|
overwritten, and the code cannot be deleted. One major goal of Crates.io is to
|
|
|
|
|
act as a permanent archive of code so that builds of all projects that depend
|
|
|
|
|
on crates from *https://crates.io* will continue to work. Allowing version
|
|
|
|
|
deletions would make fulfilling that goal impossible. However, there is no
|
|
|
|
|
limit to the number of crate versions you can publish.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Run the `cargo publish` command again. It should succeed now:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo publish
|
|
|
|
|
Updating crates.io index
|
|
|
|
|
Packaging guessing_game v0.1.0 (file:///projects/guessing_game)
|
|
|
|
|
Verifying guessing_game v0.1.0 (file:///projects/guessing_game)
|
|
|
|
|
Compiling guessing_game v0.1.0
|
|
|
|
|
(file:///projects/guessing_game/target/package/guessing_game-0.1.0)
|
|
|
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.19s
|
|
|
|
|
Uploading guessing_game v0.1.0 (file:///projects/guessing_game)
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Congratulations! You’ve now shared your code with the Rust community, and
|
|
|
|
|
anyone can easily add your crate as a dependency of their project.
|
|
|
|
|
|
|
|
|
|
### Publishing a New Version of an Existing Crate
|
|
|
|
|
|
|
|
|
|
When you’ve made changes to your crate and are ready to release a new version,
|
|
|
|
|
you change the `version` value specified in your *Cargo.toml* file and
|
2022-08-23 14:33:45 +00:00
|
|
|
|
republish. Use the Semantic Versioning rules at *http://semver.org* to decide
|
2022-08-24 13:12:29 +00:00
|
|
|
|
what an appropriate next version number is, based on the kinds of changes
|
|
|
|
|
you’ve made. Then run `cargo publish` to upload the new version.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
### Deprecating Versions from Crates.io with cargo yank
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Although you can’t remove previous versions of a crate, you can prevent any
|
|
|
|
|
future projects from adding them as a new dependency. This is useful when a
|
|
|
|
|
crate version is broken for one reason or another. In such situations, Cargo
|
2022-08-24 13:12:29 +00:00
|
|
|
|
supports yanking a crate version.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-08-24 13:12:29 +00:00
|
|
|
|
*Yanking* a version prevents new projects from depending on that version while
|
2022-04-29 12:55:43 +00:00
|
|
|
|
allowing all existing projects that depend on it to continue. Essentially, a
|
|
|
|
|
yank means that all projects with a *Cargo.lock* will not break, and any future
|
|
|
|
|
*Cargo.lock* files generated will not use the yanked version.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
To yank a version of a crate, in the directory of the crate that you’ve
|
|
|
|
|
previously published, run `cargo yank` and specify which version you want to
|
2022-08-23 14:33:45 +00:00
|
|
|
|
yank. For example, if we’ve published a crate named `guessing_game` version
|
|
|
|
|
1.0.1 and we want to yank it, in the project directory for `guessing_game` we’d
|
2022-06-04 13:42:18 +00:00
|
|
|
|
run:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo yank --vers 1.0.1
|
2022-06-04 13:42:18 +00:00
|
|
|
|
Updating crates.io index
|
2022-08-23 23:42:31 +00:00
|
|
|
|
Yank guessing_game@1.0.1
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
By adding `--undo` to the command, you can also undo a yank and allow projects
|
|
|
|
|
to start depending on a version again:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo yank --vers 1.0.1 --undo
|
2022-06-04 13:42:18 +00:00
|
|
|
|
Updating crates.io index
|
2022-08-23 23:42:31 +00:00
|
|
|
|
Unyank guessing_game@1.0.1
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
A yank *does not* delete any code. It cannot, for example, delete accidentally
|
|
|
|
|
uploaded secrets. If that happens, you must reset those secrets immediately.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
## Cargo Workspaces
|
|
|
|
|
|
|
|
|
|
In Chapter 12, we built a package that included a binary crate and a library
|
|
|
|
|
crate. As your project develops, you might find that the library crate
|
2022-04-29 12:55:43 +00:00
|
|
|
|
continues to get bigger and you want to split your package further into
|
|
|
|
|
multiple library crates. Cargo offers a feature called *workspaces* that can
|
|
|
|
|
help manage multiple related packages that are developed in tandem.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
### Creating a Workspace
|
|
|
|
|
|
|
|
|
|
A *workspace* is a set of packages that share the same *Cargo.lock* and output
|
|
|
|
|
directory. Let’s make a project using a workspace—we’ll use trivial code so we
|
|
|
|
|
can concentrate on the structure of the workspace. There are multiple ways to
|
2022-08-23 14:33:45 +00:00
|
|
|
|
structure a workspace, so we’ll just show one common way. We’ll have a
|
2022-01-08 02:37:05 +00:00
|
|
|
|
workspace containing a binary and two libraries. The binary, which will provide
|
|
|
|
|
the main functionality, will depend on the two libraries. One library will
|
2022-08-23 14:33:45 +00:00
|
|
|
|
provide an `add_one` function and the other library an `add_two` function.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
These three crates will be part of the same workspace. We’ll start by creating
|
|
|
|
|
a new directory for the workspace:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ mkdir add
|
|
|
|
|
$ cd add
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Next, in the *add* directory, we create the *Cargo.toml* file that will
|
2022-06-04 13:42:18 +00:00
|
|
|
|
configure the entire workspace. This file won’t have a `[package]` section.
|
|
|
|
|
Instead, it will start with a `[workspace]` section that will allow us to add
|
|
|
|
|
members to the workspace by specifying the path to the package with our binary
|
|
|
|
|
crate; in this case, that path is *adder*:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[workspace]
|
|
|
|
|
|
|
|
|
|
members = [
|
|
|
|
|
"adder",
|
|
|
|
|
]
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Next, we’ll create the `adder` binary crate by running `cargo new` within the
|
|
|
|
|
*add* directory:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo new adder
|
|
|
|
|
Created binary (application) `adder` package
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
At this point, we can build the workspace by running `cargo build`. The files
|
|
|
|
|
in your *add* directory should look like this:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
├── Cargo.lock
|
|
|
|
|
├── Cargo.toml
|
|
|
|
|
├── adder
|
|
|
|
|
│ ├── Cargo.toml
|
|
|
|
|
│ └── src
|
|
|
|
|
│ └── main.rs
|
|
|
|
|
└── target
|
|
|
|
|
```
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
The workspace has one *target* directory at the top level that the compiled
|
|
|
|
|
artifacts will be placed into; the `adder` package doesn’t have its own
|
|
|
|
|
*target* directory. Even if we were to run `cargo build` from inside the
|
|
|
|
|
*adder* directory, the compiled artifacts would still end up in *add/target*
|
|
|
|
|
rather than *add/adder/target*. Cargo structures the *target* directory in a
|
|
|
|
|
workspace like this because the crates in a workspace are meant to depend on
|
|
|
|
|
each other. If each crate had its own *target* directory, each crate would have
|
|
|
|
|
to recompile each of the other crates in the workspace to place the artifacts
|
|
|
|
|
in its own *target* directory. By sharing one *target* directory, the crates
|
|
|
|
|
can avoid unnecessary rebuilding.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
### Creating the Second Package in the Workspace
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Next, let’s create another member package in the workspace and call it
|
|
|
|
|
`add_one`. Change the top-level *Cargo.toml* to specify the *add_one* path in
|
|
|
|
|
the `members` list:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[workspace]
|
|
|
|
|
|
|
|
|
|
members = [
|
|
|
|
|
"adder",
|
|
|
|
|
"add_one",
|
|
|
|
|
]
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Then generate a new library crate named `add_one`:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo new add_one --lib
|
|
|
|
|
Created library `add_one` package
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Your *add* directory should now have these directories and files:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
├── Cargo.lock
|
|
|
|
|
├── Cargo.toml
|
|
|
|
|
├── add_one
|
|
|
|
|
│ ├── Cargo.toml
|
|
|
|
|
│ └── src
|
|
|
|
|
│ └── lib.rs
|
|
|
|
|
├── adder
|
|
|
|
|
│ ├── Cargo.toml
|
|
|
|
|
│ └── src
|
|
|
|
|
│ └── main.rs
|
|
|
|
|
└── target
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
In the *add_one/src/lib.rs* file, let’s add an `add_one` function:
|
|
|
|
|
|
|
|
|
|
Filename: add_one/src/lib.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
pub fn add_one(x: i32) -> i32 {
|
|
|
|
|
x + 1
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Now we can have the `adder` package with our binary depend on the `add_one`
|
2022-08-23 14:33:45 +00:00
|
|
|
|
package that has our library. First we’ll need to add a path dependency on
|
|
|
|
|
`add_one` to *adder/Cargo.toml*:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: adder/Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[dependencies]
|
|
|
|
|
add_one = { path = "../add_one" }
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Cargo doesn’t assume that crates in a workspace will depend on each other, so
|
2022-04-29 12:55:43 +00:00
|
|
|
|
we need to be explicit about the dependency relationships.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Next, let’s use the `add_one` function (from the `add_one` crate) in the
|
|
|
|
|
`adder` crate. Open the *adder/src/main.rs* file and add a `use` line at the
|
|
|
|
|
top to bring the new `add_one` library crate into scope. Then change the `main`
|
2022-01-08 02:37:05 +00:00
|
|
|
|
function to call the `add_one` function, as in Listing 14-7.
|
|
|
|
|
|
|
|
|
|
Filename: adder/src/main.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
use add_one;
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
fn main() {
|
|
|
|
|
let num = 10;
|
2022-08-23 14:33:45 +00:00
|
|
|
|
println!(
|
|
|
|
|
"Hello, world! {num} plus one is {}!",
|
|
|
|
|
add_one::add_one(num)
|
|
|
|
|
);
|
2022-01-08 02:37:05 +00:00
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2022-09-13 16:54:09 +00:00
|
|
|
|
Listing 14-7: Using the `add_one` library crate from the `adder` crate
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Let’s build the workspace by running `cargo build` in the top-level *add*
|
|
|
|
|
directory!
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo build
|
|
|
|
|
Compiling add_one v0.1.0 (file:///projects/add/add_one)
|
|
|
|
|
Compiling adder v0.1.0 (file:///projects/add/adder)
|
|
|
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.68s
|
|
|
|
|
```
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
To run the binary crate from the *add* directory, we can specify which package
|
|
|
|
|
in the workspace we want to run by using the `-p` argument and the package name
|
|
|
|
|
with `cargo run`:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo run -p adder
|
|
|
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.0s
|
|
|
|
|
Running `target/debug/adder`
|
|
|
|
|
Hello, world! 10 plus one is 11!
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This runs the code in *adder/src/main.rs*, which depends on the `add_one` crate.
|
|
|
|
|
|
|
|
|
|
#### Depending on an External Package in a Workspace
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Notice that the workspace has only one *Cargo.lock* file at the top level,
|
|
|
|
|
rather than having a *Cargo.lock* in each crate’s directory. This ensures that
|
|
|
|
|
all crates are using the same version of all dependencies. If we add the `rand`
|
|
|
|
|
package to the *adder/Cargo.toml* and *add_one/Cargo.toml* files, Cargo will
|
|
|
|
|
resolve both of those to one version of `rand` and record that in the one
|
|
|
|
|
*Cargo.lock*. Making all crates in the workspace use the same dependencies
|
|
|
|
|
means the crates will always be compatible with each other. Let’s add the
|
|
|
|
|
`rand` crate to the `[dependencies]` section in the *add_one/Cargo.toml* file
|
|
|
|
|
so we can use the `rand` crate in the `add_one` crate:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Filename: add_one/Cargo.toml
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
[dependencies]
|
2022-08-23 14:28:28 +00:00
|
|
|
|
rand = "0.8.5"
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
We can now add `use rand;` to the *add_one/src/lib.rs* file, and building the
|
|
|
|
|
whole workspace by running `cargo build` in the *add* directory will bring in
|
|
|
|
|
and compile the `rand` crate. We will get one warning because we aren’t
|
|
|
|
|
referring to the `rand` we brought into scope:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo build
|
|
|
|
|
Updating crates.io index
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Downloaded rand v0.8.5
|
2022-08-23 23:42:31 +00:00
|
|
|
|
--snip--
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Compiling rand v0.8.5
|
2022-01-08 02:37:05 +00:00
|
|
|
|
Compiling add_one v0.1.0 (file:///projects/add/add_one)
|
|
|
|
|
Compiling adder v0.1.0 (file:///projects/add/adder)
|
|
|
|
|
Finished dev [unoptimized + debuginfo] target(s) in 10.18s
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The top-level *Cargo.lock* now contains information about the dependency of
|
|
|
|
|
`add_one` on `rand`. However, even though `rand` is used somewhere in the
|
|
|
|
|
workspace, we can’t use it in other crates in the workspace unless we add
|
|
|
|
|
`rand` to their *Cargo.toml* files as well. For example, if we add `use rand;`
|
|
|
|
|
to the *adder/src/main.rs* file for the `adder` package, we’ll get an error:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo build
|
2022-08-23 14:33:45 +00:00
|
|
|
|
--snip--
|
2022-01-08 02:37:05 +00:00
|
|
|
|
Compiling adder v0.1.0 (file:///projects/add/adder)
|
|
|
|
|
error[E0432]: unresolved import `rand`
|
|
|
|
|
--> adder/src/main.rs:2:5
|
|
|
|
|
|
|
|
|
|
|
2 | use rand;
|
|
|
|
|
| ^^^^ no external crate `rand`
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
To fix this, edit the *Cargo.toml* file for the `adder` package and indicate
|
|
|
|
|
that `rand` is a dependency for it as well. Building the `adder` package will
|
|
|
|
|
add `rand` to the list of dependencies for `adder` in *Cargo.lock*, but no
|
|
|
|
|
additional copies of `rand` will be downloaded. Cargo has ensured that every
|
2022-04-29 12:55:43 +00:00
|
|
|
|
crate in every package in the workspace using the `rand` package will be using
|
|
|
|
|
the same version, saving us space and ensuring that the crates in the workspace
|
|
|
|
|
will be compatible with each other.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
#### Adding a Test to a Workspace
|
|
|
|
|
|
|
|
|
|
For another enhancement, let’s add a test of the `add_one::add_one` function
|
|
|
|
|
within the `add_one` crate:
|
|
|
|
|
|
|
|
|
|
Filename: add_one/src/lib.rs
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
pub fn add_one(x: i32) -> i32 {
|
|
|
|
|
x + 1
|
|
|
|
|
}
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
#[cfg(test)]
|
|
|
|
|
mod tests {
|
|
|
|
|
use super::*;
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
#[test]
|
|
|
|
|
fn it_works() {
|
|
|
|
|
assert_eq!(3, add_one(2));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
2022-04-29 12:55:43 +00:00
|
|
|
|
Now run `cargo test` in the top-level *add* directory. Running `cargo test` in
|
|
|
|
|
a workspace structured like this one will run the tests for all the crates in
|
|
|
|
|
the workspace:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo test
|
|
|
|
|
Compiling add_one v0.1.0 (file:///projects/add/add_one)
|
|
|
|
|
Compiling adder v0.1.0 (file:///projects/add/adder)
|
|
|
|
|
Finished test [unoptimized + debuginfo] target(s) in 0.27s
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Running unittests src/lib.rs (target/debug/deps/add_one-f0253159197f7841)
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
running 1 test
|
|
|
|
|
test tests::it_works ... ok
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out;
|
|
|
|
|
finished in 0.00s
|
|
|
|
|
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Running unittests src/main.rs (target/debug/deps/adder-49979ff40686fa8e)
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
running 0 tests
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
|
|
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out;
|
|
|
|
|
finished in 0.00s
|
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
Doc-tests add_one
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
running 0 tests
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
|
|
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out;
|
|
|
|
|
finished in 0.00s
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The first section of the output shows that the `it_works` test in the `add_one`
|
|
|
|
|
crate passed. The next section shows that zero tests were found in the `adder`
|
|
|
|
|
crate, and then the last section shows zero documentation tests were found in
|
2022-04-29 12:55:43 +00:00
|
|
|
|
the `add_one` crate.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
We can also run tests for one particular crate in a workspace from the
|
|
|
|
|
top-level directory by using the `-p` flag and specifying the name of the crate
|
|
|
|
|
we want to test:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo test -p add_one
|
|
|
|
|
Finished test [unoptimized + debuginfo] target(s) in 0.00s
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Running unittests src/lib.rs (target/debug/deps/add_one-b3235fea9a156f74)
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
running 1 test
|
|
|
|
|
test tests::it_works ... ok
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
|
|
|
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out;
|
|
|
|
|
finished in 0.00s
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
Doc-tests add_one
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
2022-01-08 02:37:05 +00:00
|
|
|
|
running 0 tests
|
2022-08-23 14:33:45 +00:00
|
|
|
|
|
|
|
|
|
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out;
|
|
|
|
|
finished in 0.00s
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This output shows `cargo test` only ran the tests for the `add_one` crate and
|
|
|
|
|
didn’t run the `adder` crate tests.
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
If you publish the crates in the workspace to *https://crates.io*, each crate
|
|
|
|
|
in the workspace will need to be published separately. Like `cargo test`, we
|
|
|
|
|
can publish a particular crate in our workspace by using the `-p` flag and
|
|
|
|
|
specifying the name of the crate we want to publish.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
For additional practice, add an `add_two` crate to this workspace in a similar
|
|
|
|
|
way as the `add_one` crate!
|
|
|
|
|
|
2022-08-23 23:42:31 +00:00
|
|
|
|
As your project grows, consider using a workspace: it provides
|
|
|
|
|
easier-to-understand, smaller, individual components than one big blob of code.
|
|
|
|
|
Furthermore, keeping the crates in a workspace can make coordination between
|
|
|
|
|
crates easier if they are often changed at the same time.
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
## Installing Binaries with cargo install
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
The `cargo install` command allows you to install and use binary crates
|
|
|
|
|
locally. This isn’t intended to replace system packages; it’s meant to be a
|
|
|
|
|
convenient way for Rust developers to install tools that others have shared on
|
2022-08-23 14:33:45 +00:00
|
|
|
|
*https://crates.io*. Note that you can only install packages that have binary
|
|
|
|
|
targets. A *binary target* is the runnable program that is created if the crate
|
2022-08-24 13:12:29 +00:00
|
|
|
|
has a *src/main.rs* file or another file specified as a binary, as opposed to a
|
|
|
|
|
library target that isn’t runnable on its own but is suitable for including
|
2022-08-23 23:42:31 +00:00
|
|
|
|
within other programs. Usually, crates have information in the *README* file
|
2022-01-08 02:37:05 +00:00
|
|
|
|
about whether a crate is a library, has a binary target, or both.
|
|
|
|
|
|
|
|
|
|
All binaries installed with `cargo install` are stored in the installation
|
|
|
|
|
root’s *bin* folder. If you installed Rust using *rustup.rs* and don’t have any
|
|
|
|
|
custom configurations, this directory will be *$HOME/.cargo/bin*. Ensure that
|
|
|
|
|
directory is in your `$PATH` to be able to run programs you’ve installed with
|
|
|
|
|
`cargo install`.
|
|
|
|
|
|
|
|
|
|
For example, in Chapter 12 we mentioned that there’s a Rust implementation of
|
2022-04-29 12:55:43 +00:00
|
|
|
|
the `grep` tool called `ripgrep` for searching files. To install `ripgrep`, we
|
|
|
|
|
can run the following:
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
$ cargo install ripgrep
|
|
|
|
|
Updating crates.io index
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Downloaded ripgrep v13.0.0
|
2022-01-08 02:37:05 +00:00
|
|
|
|
Downloaded 1 crate (243.3 KB) in 0.88s
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Installing ripgrep v13.0.0
|
2022-08-23 23:42:31 +00:00
|
|
|
|
--snip--
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Compiling ripgrep v13.0.0
|
2022-01-08 02:37:05 +00:00
|
|
|
|
Finished release [optimized + debuginfo] target(s) in 3m 10s
|
|
|
|
|
Installing ~/.cargo/bin/rg
|
2022-08-23 14:28:28 +00:00
|
|
|
|
Installed package `ripgrep v13.0.0` (executable `rg`)
|
2022-01-08 02:37:05 +00:00
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The second-to-last line of the output shows the location and the name of the
|
|
|
|
|
installed binary, which in the case of `ripgrep` is `rg`. As long as the
|
|
|
|
|
installation directory is in your `$PATH`, as mentioned previously, you can
|
2022-08-23 23:42:31 +00:00
|
|
|
|
then run `rg --help` and start using a faster, Rustier tool for searching files!
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
## Extending Cargo with Custom Commands
|
|
|
|
|
|
|
|
|
|
Cargo is designed so you can extend it with new subcommands without having to
|
2022-08-23 14:33:45 +00:00
|
|
|
|
modify it. If a binary in your `$PATH` is named `cargo-something`, you can run
|
|
|
|
|
it as if it were a Cargo subcommand by running `cargo something`. Custom
|
2022-01-08 02:37:05 +00:00
|
|
|
|
commands like this are also listed when you run `cargo --list`. Being able to
|
|
|
|
|
use `cargo install` to install extensions and then run them just like the
|
2022-08-23 14:33:45 +00:00
|
|
|
|
built-in Cargo tools is a super-convenient benefit of Cargo’s design!
|
2022-01-08 02:37:05 +00:00
|
|
|
|
|
|
|
|
|
## Summary
|
|
|
|
|
|
2022-08-23 14:33:45 +00:00
|
|
|
|
Sharing code with Cargo and *https://crates.io* is part of what makes the Rust
|
|
|
|
|
ecosystem useful for many different tasks. Rust’s standard library is small and
|
|
|
|
|
stable, but crates are easy to share, use, and improve on a timeline different
|
|
|
|
|
from that of the language. Don’t be shy about sharing code that’s useful to you
|
|
|
|
|
on *https://crates.io*; it’s likely that it will be useful to someone else as
|
|
|
|
|
well!
|
|
|
|
|
|