53 lines
3.3 KiB
HTML
53 lines
3.3 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<title>Packages, Crates, and Modules</title>
|
||
</head>
|
||
<body>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="managing-growing-projects-with-packages-crates-and-modules"></a></p>
|
||
<h1 id="packages-crates-and-modules"><a class="header" href="#packages-crates-and-modules">Packages, Crates, and Modules</a></h1>
|
||
<p>As you write large programs, organizing your code will become increasingly
|
||
important. By grouping related functionality and separating code with distinct
|
||
features, you’ll clarify where to find code that implements a particular
|
||
feature and where to go to change how a feature works.</p>
|
||
<p>The programs we’ve written so far have been in one module in one file. As a
|
||
project grows, you should organize code by splitting it into multiple modules
|
||
and then multiple files. A package can contain multiple binary crates and
|
||
optionally one library crate. As a package grows, you can extract parts into
|
||
separate crates that become external dependencies. This chapter covers all
|
||
these techniques. For very large projects comprising a set of interrelated
|
||
packages that evolve together, Cargo provides workspaces, which we’ll cover in
|
||
<a href="../ch14/ch14-03-cargo-workspaces.html">“Cargo Workspaces”</a><!-- ignore --> in Chapter 14.</p>
|
||
<p>We’ll also discuss encapsulating implementation details, which lets you reuse
|
||
code at a higher level: Once you’ve implemented an operation, other code can
|
||
call your code via its public interface without having to know how the
|
||
implementation works. The way you write code defines which parts are public for
|
||
other code to use and which parts are private implementation details that you
|
||
reserve the right to change. This is another way to limit the amount of detail
|
||
you have to keep in your head.</p>
|
||
<p>A related concept is scope: The nested context in which code is written has a
|
||
set of names that are defined as “in scope.” When reading, writing, and
|
||
compiling code, programmers and compilers need to know whether a particular
|
||
name at a particular spot refers to a variable, function, struct, enum, module,
|
||
constant, or other item and what that item means. You can create scopes and
|
||
change which names are in or out of scope. You can’t have two items with the
|
||
same name in the same scope; tools are available to resolve name conflicts.</p>
|
||
<p>Rust has a number of features that allow you to manage your code’s
|
||
organization, including which details are exposed, which details are private,
|
||
and what names are in each scope in your programs. These features, sometimes
|
||
collectively referred to as the <em>module system</em>, include:</p>
|
||
<ul>
|
||
<li><strong>Packages</strong>: A Cargo feature that lets you build, test, and share crates</li>
|
||
<li><strong>Crates</strong>: A tree of modules that produces a library or executable</li>
|
||
<li><strong>Modules and use</strong>: Let you control the organization, scope, and privacy of
|
||
paths</li>
|
||
<li><strong>Paths</strong>: A way of naming an item, such as a struct, function, or module</li>
|
||
</ul>
|
||
<p>In this chapter, we’ll cover all these features, discuss how they interact, and
|
||
explain how to use them to manage scope. By the end, you should have a solid
|
||
understanding of the module system and be able to work with scopes like a pro!</p>
|
||
</body>
|
||
</html>
|