625 lines
49 KiB
HTML
625 lines
49 KiB
HTML
|
<!DOCTYPE HTML>
|
|||
|
<html lang="en" class="sidebar-visible no-js light">
|
|||
|
<head>
|
|||
|
<!-- Book generated using mdBook -->
|
|||
|
<meta charset="UTF-8">
|
|||
|
<title>Publishing a Crate to Crates.io - The Rust Programming Language</title>
|
|||
|
|
|||
|
|
|||
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|||
|
<meta name="description" content="">
|
|||
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|||
|
<meta name="theme-color" content="#ffffff" />
|
|||
|
|
|||
|
<link rel="shortcut icon" href="favicon.png">
|
|||
|
<link rel="stylesheet" href="css/variables.css">
|
|||
|
<link rel="stylesheet" href="css/general.css">
|
|||
|
<link rel="stylesheet" href="css/chrome.css">
|
|||
|
<link rel="stylesheet" href="css/print.css" media="print">
|
|||
|
|
|||
|
<!-- Fonts -->
|
|||
|
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
|
|||
|
<link href="googleFonts/css.css" rel="stylesheet" type="text/css">
|
|||
|
|
|||
|
<!-- Highlight.js Stylesheets -->
|
|||
|
<link rel="stylesheet" href="highlight.css">
|
|||
|
<link rel="stylesheet" href="tomorrow-night.css">
|
|||
|
<link rel="stylesheet" href="ayu-highlight.css">
|
|||
|
|
|||
|
<!-- Custom theme stylesheets -->
|
|||
|
|
|||
|
<link rel="stylesheet" href="ferris.css">
|
|||
|
|
|||
|
<link rel="stylesheet" href="theme/2018-edition.css">
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
<!-- Provide site root to javascript -->
|
|||
|
<script type="text/javascript">
|
|||
|
var path_to_root = "";
|
|||
|
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "light" : "light";
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|||
|
<script type="text/javascript">
|
|||
|
try {
|
|||
|
var theme = localStorage.getItem('mdbook-theme');
|
|||
|
var sidebar = localStorage.getItem('mdbook-sidebar');
|
|||
|
|
|||
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|||
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|||
|
}
|
|||
|
|
|||
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|||
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|||
|
}
|
|||
|
} catch (e) { }
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|||
|
<script type="text/javascript">
|
|||
|
var theme;
|
|||
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|||
|
if (theme === null || theme === undefined) { theme = default_theme; }
|
|||
|
var html = document.querySelector('html');
|
|||
|
html.classList.remove('no-js')
|
|||
|
html.classList.remove('light')
|
|||
|
html.classList.add(theme);
|
|||
|
html.classList.add('js');
|
|||
|
</script>
|
|||
|
|
|||
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|||
|
<script type="text/javascript">
|
|||
|
var html = document.querySelector('html');
|
|||
|
var sidebar = 'hidden';
|
|||
|
if (document.body.clientWidth >= 1080) {
|
|||
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|||
|
sidebar = sidebar || 'visible';
|
|||
|
}
|
|||
|
html.classList.remove('sidebar-visible');
|
|||
|
html.classList.add("sidebar-" + sidebar);
|
|||
|
</script>
|
|||
|
|
|||
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|||
|
<div id="sidebar-scrollbox" class="sidebar-scrollbox">
|
|||
|
<ol class="chapter"><li class="expanded affix "><a href="title-page.html">The Rust Programming Language</a></li><li class="expanded affix "><a href="foreword.html">Foreword</a></li><li class="expanded affix "><a href="ch00-00-introduction.html">Introduction</a></li><li class="expanded "><a href="ch01-00-getting-started.html"><strong aria-hidden="true">1.</strong> Getting Started</a></li><li><ol class="section"><li class="expanded "><a href="ch01-01-installation.html"><strong aria-hidden="true">1.1.</strong> Installation</a></li><li class="expanded "><a href="ch01-02-hello-world.html"><strong aria-hidden="true">1.2.</strong> Hello, World!</a></li><li class="expanded "><a href="ch01-03-hello-cargo.html"><strong aria-hidden="true">1.3.</strong> Hello, Cargo!</a></li></ol></li><li class="expanded "><a href="ch02-00-guessing-game-tutorial.html"><strong aria-hidden="true">2.</strong> Programming a Guessing Game</a></li><li class="expanded "><a href="ch03-00-common-programming-concepts.html"><strong aria-hidden="true">3.</strong> Common Programming Concepts</a></li><li><ol class="section"><li class="expanded "><a href="ch03-01-variables-and-mutability.html"><strong aria-hidden="true">3.1.</strong> Variables and Mutability</a></li><li class="expanded "><a href="ch03-02-data-types.html"><strong aria-hidden="true">3.2.</strong> Data Types</a></li><li class="expanded "><a href="ch03-03-how-functions-work.html"><strong aria-hidden="true">3.3.</strong> Functions</a></li><li class="expanded "><a href="ch03-04-comments.html"><strong aria-hidden="true">3.4.</strong> Comments</a></li><li class="expanded "><a href="ch03-05-control-flow.html"><strong aria-hidden="true">3.5.</strong> Control Flow</a></li></ol></li><li class="expanded "><a href="ch04-00-understanding-ownership.html"><strong aria-hidden="true">4.</strong> Understanding Ownership</a></li><li><ol class="section"><li class="expanded "><a href="ch04-01-what-is-ownership.html"><strong aria-hidden="true">4.1.</strong> What is Ownership?</a></li><li class="expanded "><a href="ch04-02-references-and-borrowing.html"><strong aria-hidden="true">4.2.</strong> References and Borrowing</a></li><li class="expanded "><a href="ch04-03-slices.html"><strong aria-hidden="true">4.3.</strong> The Slice Type</a></li></ol></li><li class="expanded "><a href="ch05-00-structs.html"><strong aria-hidden="true">5.</strong> Using Structs to Structure Related Data</a></li><li><ol class="section"><li class="expanded "><a href="ch05-01-defining-structs.html"><strong aria-hidden="true">5.1.</strong> Defining and Instantiating Structs</a></li><li class="expanded "><a href="ch05-02-example-structs.html"><strong aria-hidden="true">5.2.</strong> An Example Program Using Structs</a></li><li class="expanded "><a href="ch05-03-method-syntax.html"><strong aria-hidden="true">5.3.</strong> Method Syntax</a></li></ol></li><li class="expanded "><a href="ch06-00-enums.html"><strong aria-hidden="true">6.</strong> Enums and Pattern Matching</a></li><li><ol class="section"><li class="expanded "><a href="ch06-01-defining-an-enum.html"><strong aria-hidden="true">6.1.</strong> Defining an Enum</a></li><li class="expanded "><a href="ch06-02-match.html"><strong aria-hidden="true">6.2.</strong> The match Control Flow Operator</a></li><li class="expanded "><a href="ch06-03-if-let.html"><strong aria-hidden="true">6.3.</strong> Concise Control Flow with if let</a></li></ol></li><li class="expanded "><a href="ch07-00-managing-growing-projects-with-packages-crates-and-modules.html"><strong aria-hidden="true">7.</strong> Managing Growing Projects with Packages, Crates, and Modules</a></li><li><ol class="section"><li class="expanded "><a href="ch07-01-packages-and-crates.html"><strong aria-hidden="true">7.1.</strong> Packages and Crates</a></li><li class="expanded "><a href="ch07-02-defining-modules-to-control-scope-and-privacy.html"><strong aria-hidden="true">7.2.</strong> Defining Modules to Control Scope and Privacy</a></li><li class="expanded "><a href="ch07-03-paths-for-referring-to-an-item-in-the-module-tree.html"><
|
|||
|
</div>
|
|||
|
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
|||
|
</nav>
|
|||
|
|
|||
|
<div id="page-wrapper" class="page-wrapper">
|
|||
|
|
|||
|
<div class="page">
|
|||
|
|
|||
|
<div id="menu-bar" class="menu-bar">
|
|||
|
<div id="menu-bar-sticky-container">
|
|||
|
<div class="left-buttons">
|
|||
|
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|||
|
<i class="fa fa-bars"></i>
|
|||
|
</button>
|
|||
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|||
|
<i class="fa fa-paint-brush"></i>
|
|||
|
</button>
|
|||
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|||
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|||
|
</ul>
|
|||
|
|
|||
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|||
|
<i class="fa fa-search"></i>
|
|||
|
</button>
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
<h1 class="menu-title">The Rust Programming Language</h1>
|
|||
|
|
|||
|
<div class="right-buttons">
|
|||
|
<a href="print.html" title="Print this book" aria-label="Print this book">
|
|||
|
<i id="print-button" class="fa fa-print"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<div id="search-wrapper" class="hidden">
|
|||
|
<form id="searchbar-outer" class="searchbar-outer">
|
|||
|
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|||
|
</form>
|
|||
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|||
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|||
|
<ul id="searchresults">
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|||
|
<script type="text/javascript">
|
|||
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|||
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|||
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|||
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|||
|
});
|
|||
|
</script>
|
|||
|
|
|||
|
<div id="content" class="content">
|
|||
|
<main>
|
|||
|
<h2><a class="header" href="#publishing-a-crate-to-cratesio" id="publishing-a-crate-to-cratesio">Publishing a Crate to Crates.io</a></h2>
|
|||
|
<p>We’ve used packages from <a href="https://crates.io/">crates.io</a><!-- ignore --> as
|
|||
|
dependencies of our project, but you can also share your code with other people
|
|||
|
by publishing your own packages. The crate registry at
|
|||
|
<a href="https://crates.io/">crates.io</a><!-- ignore --> distributes the source code of
|
|||
|
your packages, so it primarily hosts code that is open source.</p>
|
|||
|
<p>Rust and Cargo have features that help make your published package easier for
|
|||
|
people to use and to find in the first place. We’ll talk about some of these
|
|||
|
features next and then explain how to publish a package.</p>
|
|||
|
<h3><a class="header" href="#making-useful-documentation-comments" id="making-useful-documentation-comments">Making Useful Documentation Comments</a></h3>
|
|||
|
<p>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, <code>//</code>. Rust also has
|
|||
|
a particular kind of comment for documentation, known conveniently as a
|
|||
|
<em>documentation comment</em>, 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 <em>use</em> your crate as opposed to how
|
|||
|
your crate is <em>implemented</em>.</p>
|
|||
|
<p>Documentation comments use three slashes, <code>///</code>, 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 <code>add_one</code> function in a crate named <code>my_crate</code>:</p>
|
|||
|
<p><span class="filename">Filename: src/lib.rs</span></p>
|
|||
|
<pre><code class="language-rust ignore">/// Adds one to the number given.
|
|||
|
///
|
|||
|
/// # Examples
|
|||
|
///
|
|||
|
/// ```
|
|||
|
/// let arg = 5;
|
|||
|
/// let answer = my_crate::add_one(arg);
|
|||
|
///
|
|||
|
/// assert_eq!(6, answer);
|
|||
|
/// ```
|
|||
|
pub fn add_one(x: i32) -> i32 {
|
|||
|
x + 1
|
|||
|
}
|
|||
|
</code></pre>
|
|||
|
<p><span class="caption">Listing 14-1: A documentation comment for a
|
|||
|
function</span></p>
|
|||
|
<p>Here, we give a description of what the <code>add_one</code> function does, start a
|
|||
|
section with the heading <code>Examples</code>, and then provide code that demonstrates
|
|||
|
how to use the <code>add_one</code> function. We can generate the HTML documentation from
|
|||
|
this documentation comment by running <code>cargo doc</code>. This command runs the
|
|||
|
<code>rustdoc</code> tool distributed with Rust and puts the generated HTML documentation
|
|||
|
in the <em>target/doc</em> directory.</p>
|
|||
|
<p>For convenience, running <code>cargo doc --open</code> 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
|
|||
|
<code>add_one</code> function and you’ll see how the text in the documentation comments is
|
|||
|
rendered, as shown in Figure 14-1:</p>
|
|||
|
<img alt="Rendered HTML documentation for the `add_one` function of `my_crate`" src="img/trpl14-01.png" class="center" />
|
|||
|
<p><span class="caption">Figure 14-1: HTML documentation for the <code>add_one</code>
|
|||
|
function</span></p>
|
|||
|
<h4><a class="header" href="#commonly-used-sections" id="commonly-used-sections">Commonly Used Sections</a></h4>
|
|||
|
<p>We used the <code># Examples</code> 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:</p>
|
|||
|
<ul>
|
|||
|
<li><strong>Panics</strong>: 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.</li>
|
|||
|
<li><strong>Errors</strong>: If the function returns a <code>Result</code>, 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.</li>
|
|||
|
<li><strong>Safety</strong>: If the function is <code>unsafe</code> 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.</li>
|
|||
|
</ul>
|
|||
|
<p>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 that people calling
|
|||
|
your code will be interested in knowing about.</p>
|
|||
|
<h4><a class="header" href="#documentation-comments-as-tests" id="documentation-comments-as-tests">Documentation Comments as Tests</a></h4>
|
|||
|
<p>Adding example code blocks in your documentation comments can help demonstrate
|
|||
|
how to use your library, and doing so has an additional bonus: running <code>cargo test</code> 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 <code>cargo test</code> with the documentation for the <code>add_one</code>
|
|||
|
function from Listing 14-1, we will see a section in the test results like this:</p>
|
|||
|
<pre><code class="language-text"> Doc-tests my_crate
|
|||
|
|
|||
|
running 1 test
|
|||
|
test src/lib.rs - add_one (line 5) ... ok
|
|||
|
|
|||
|
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
|
|||
|
</code></pre>
|
|||
|
<p>Now if we change either the function or the example so the <code>assert_eq!</code> in the
|
|||
|
example panics and run <code>cargo test</code> again, we’ll see that the doc tests catch
|
|||
|
that the example and the code are out of sync with each other!</p>
|
|||
|
<h4><a class="header" href="#commenting-contained-items" id="commenting-contained-items">Commenting Contained Items</a></h4>
|
|||
|
<p>Another style of doc comment, <code>//!</code>, adds documentation to the item that
|
|||
|
contains the comments rather than adding documentation to the items following
|
|||
|
the comments. We typically use these doc comments inside the crate root file
|
|||
|
(<em>src/lib.rs</em> by convention) or inside a module to document the crate or the
|
|||
|
module as a whole.</p>
|
|||
|
<p>For example, if we want to add documentation that describes the purpose of the
|
|||
|
<code>my_crate</code> crate that contains the <code>add_one</code> function, we can add documentation
|
|||
|
comments that start with <code>//!</code> to the beginning of the <em>src/lib.rs</em> file, as
|
|||
|
shown in Listing 14-2:</p>
|
|||
|
<p><span class="filename">Filename: src/lib.rs</span></p>
|
|||
|
<pre><code class="language-rust ignore">//! # My Crate
|
|||
|
//!
|
|||
|
//! `my_crate` is a collection of utilities to make performing certain
|
|||
|
//! calculations more convenient.
|
|||
|
|
|||
|
/// Adds one to the number given.
|
|||
|
// --snip--
|
|||
|
</code></pre>
|
|||
|
<p><span class="caption">Listing 14-2: Documentation for the <code>my_crate</code> crate as a
|
|||
|
whole</span></p>
|
|||
|
<p>Notice there isn’t any code after the last line that begins with <code>//!</code>. Because
|
|||
|
we started the comments with <code>//!</code> instead of <code>///</code>, we’re documenting the item
|
|||
|
that contains this comment rather than an item that follows this comment. In
|
|||
|
this case, the item that contains this comment is the <em>src/lib.rs</em> file, which
|
|||
|
is the crate root. These comments describe the entire crate.</p>
|
|||
|
<p>When we run <code>cargo doc --open</code>, these comments will display on the front
|
|||
|
page of the documentation for <code>my_crate</code> above the list of public items in the
|
|||
|
crate, as shown in Figure 14-2:</p>
|
|||
|
<img alt="Rendered HTML documentation with a comment for the crate as a whole" src="img/trpl14-02.png" class="center" />
|
|||
|
<p><span class="caption">Figure 14-2: Rendered documentation for <code>my_crate</code>,
|
|||
|
including the comment describing the crate as a whole</span></p>
|
|||
|
<p>Documentation comments within items are useful for describing crates and
|
|||
|
modules especially. Use them to explain the overall purpose of the container to
|
|||
|
help your users understand the crate’s organization.</p>
|
|||
|
<h3><a class="header" href="#exporting-a-convenient-public-api-with-pub-use" id="exporting-a-convenient-public-api-with-pub-use">Exporting a Convenient Public API with <code>pub use</code></a></h3>
|
|||
|
<p>In Chapter 7, we covered how to organize our code into modules using the <code>mod</code>
|
|||
|
keyword, how to make items public using the <code>pub</code> keyword, and how to bring
|
|||
|
items into a scope with the <code>use</code> 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 <code>use</code>
|
|||
|
<code>my_crate::some_module::another_module::UsefulType;</code> rather than <code>use</code>
|
|||
|
<code>my_crate::UsefulType;</code>.</p>
|
|||
|
<p>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.</p>
|
|||
|
<p>The good news is that if the structure <em>isn’t</em> 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
|
|||
|
from your private structure by using <code>pub use</code>. Re-exporting takes a public
|
|||
|
item in one location and makes it public in another location, as if it were
|
|||
|
defined in the other location instead.</p>
|
|||
|
<p>For example, say we made a library named <code>art</code> for modeling artistic concepts.
|
|||
|
Within this library are two modules: a <code>kinds</code> module containing two enums
|
|||
|
named <code>PrimaryColor</code> and <code>SecondaryColor</code> and a <code>utils</code> module containing a
|
|||
|
function named <code>mix</code>, as shown in Listing 14-3:</p>
|
|||
|
<p><span class="filename">Filename: src/lib.rs</span></p>
|
|||
|
<pre><pre class="playpen"><code class="language-rust">//! # Art
|
|||
|
//!
|
|||
|
//! A library for modeling artistic concepts.
|
|||
|
|
|||
|
pub mod kinds {
|
|||
|
/// The primary colors according to the RYB color model.
|
|||
|
pub enum PrimaryColor {
|
|||
|
Red,
|
|||
|
Yellow,
|
|||
|
Blue,
|
|||
|
}
|
|||
|
|
|||
|
/// The secondary colors according to the RYB color model.
|
|||
|
pub enum SecondaryColor {
|
|||
|
Orange,
|
|||
|
Green,
|
|||
|
Purple,
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
pub mod utils {
|
|||
|
use crate::kinds::*;
|
|||
|
|
|||
|
/// Combines two primary colors in equal amounts to create
|
|||
|
/// a secondary color.
|
|||
|
pub fn mix(c1: PrimaryColor, c2: PrimaryColor) -> SecondaryColor {
|
|||
|
// --snip--
|
|||
|
<span class="boring"> SecondaryColor::Orange
|
|||
|
</span> }
|
|||
|
}
|
|||
|
<span class="boring">fn main() {}
|
|||
|
</span></code></pre></pre>
|
|||
|
<p><span class="caption">Listing 14-3: An <code>art</code> library with items organized into
|
|||
|
<code>kinds</code> and <code>utils</code> modules</span></p>
|
|||
|
<p>Figure 14-3 shows what the front page of the documentation for this crate
|
|||
|
generated by <code>cargo doc</code> would look like:</p>
|
|||
|
<img alt="Rendered documentation for the `art` crate that lists the `kinds` and `utils` modules" src="img/trpl14-03.png" class="center" />
|
|||
|
<p><span class="caption">Figure 14-3: Front page of the documentation for <code>art</code>
|
|||
|
that lists the <code>kinds</code> and <code>utils</code> modules</span></p>
|
|||
|
<p>Note that the <code>PrimaryColor</code> and <code>SecondaryColor</code> types aren’t listed on the
|
|||
|
front page, nor is the <code>mix</code> function. We have to click <code>kinds</code> and <code>utils</code> to
|
|||
|
see them.</p>
|
|||
|
<p>Another crate that depends on this library would need <code>use</code> statements that
|
|||
|
bring the items from <code>art</code> into scope, specifying the module structure that’s
|
|||
|
currently defined. Listing 14-4 shows an example of a crate that uses the
|
|||
|
<code>PrimaryColor</code> and <code>mix</code> items from the <code>art</code> crate:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><code class="language-rust ignore">use art::kinds::PrimaryColor;
|
|||
|
use art::utils::mix;
|
|||
|
|
|||
|
fn main() {
|
|||
|
let red = PrimaryColor::Red;
|
|||
|
let yellow = PrimaryColor::Yellow;
|
|||
|
mix(red, yellow);
|
|||
|
}
|
|||
|
</code></pre>
|
|||
|
<p><span class="caption">Listing 14-4: A crate using the <code>art</code> crate’s items with
|
|||
|
its internal structure exported</span></p>
|
|||
|
<p>The author of the code in Listing 14-4, which uses the <code>art</code> crate, had to
|
|||
|
figure out that <code>PrimaryColor</code> is in the <code>kinds</code> module and <code>mix</code> is in the
|
|||
|
<code>utils</code> module. The module structure of the <code>art</code> crate is more relevant to
|
|||
|
developers working on the <code>art</code> crate than to developers using the <code>art</code> crate.
|
|||
|
The internal structure that organizes parts of the crate into the <code>kinds</code>
|
|||
|
module and the <code>utils</code> module doesn’t contain any useful information for
|
|||
|
someone trying to understand how to use the <code>art</code> crate. Instead, the <code>art</code>
|
|||
|
crate’s module structure causes confusion because developers have to figure out
|
|||
|
where to look, and the structure is inconvenient because developers must
|
|||
|
specify the module names in the <code>use</code> statements.</p>
|
|||
|
<p>To remove the internal organization from the public API, we can modify the
|
|||
|
<code>art</code> crate code in Listing 14-3 to add <code>pub use</code> statements to re-export the
|
|||
|
items at the top level, as shown in Listing 14-5:</p>
|
|||
|
<p><span class="filename">Filename: src/lib.rs</span></p>
|
|||
|
<pre><code class="language-rust ignore">//! # 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 {
|
|||
|
// --snip--
|
|||
|
}
|
|||
|
|
|||
|
pub mod utils {
|
|||
|
// --snip--
|
|||
|
}
|
|||
|
</code></pre>
|
|||
|
<p><span class="caption">Listing 14-5: Adding <code>pub use</code> statements to re-export
|
|||
|
items</span></p>
|
|||
|
<p>The API documentation that <code>cargo doc</code> generates for this crate will now list
|
|||
|
and link re-exports on the front page, as shown in Figure 14-4, making the
|
|||
|
<code>PrimaryColor</code> and <code>SecondaryColor</code> types and the <code>mix</code> function easier to find.</p>
|
|||
|
<img alt="Rendered documentation for the `art` crate with the re-exports on the front page" src="img/trpl14-04.png" class="center" />
|
|||
|
<p><span class="caption">Figure 14-4: The front page of the documentation for <code>art</code>
|
|||
|
that lists the re-exports</span></p>
|
|||
|
<p>The <code>art</code> 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:</p>
|
|||
|
<p><span class="filename">Filename: src/main.rs</span></p>
|
|||
|
<pre><code class="language-rust ignore">use art::PrimaryColor;
|
|||
|
use art::mix;
|
|||
|
|
|||
|
fn main() {
|
|||
|
// --snip--
|
|||
|
}
|
|||
|
</code></pre>
|
|||
|
<p><span class="caption">Listing 14-6: A program using the re-exported items from
|
|||
|
the <code>art</code> crate</span></p>
|
|||
|
<p>In cases where there are many nested modules, re-exporting the types at the top
|
|||
|
level with <code>pub use</code> can make a significant difference in the experience of
|
|||
|
people who use the crate.</p>
|
|||
|
<p>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 <code>pub use</code> 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.</p>
|
|||
|
<h3><a class="header" href="#setting-up-a-cratesio-account" id="setting-up-a-cratesio-account">Setting Up a Crates.io Account</a></h3>
|
|||
|
<p>Before you can publish any crates, you need to create an account on
|
|||
|
<a href="https://crates.io/">crates.io</a><!-- ignore --> and get an API token. To do so,
|
|||
|
visit the home page at <a href="https://crates.io/">crates.io</a><!-- ignore --> 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
|
|||
|
<a href="https://crates.io/me/">https://crates.io/me/</a><!-- ignore --> and retrieve your
|
|||
|
API key. Then run the <code>cargo login</code> command with your API key, like this:</p>
|
|||
|
<pre><code class="language-text">$ cargo login abcdefghijklmnopqrstuvwxyz012345
|
|||
|
</code></pre>
|
|||
|
<p>This command will inform Cargo of your API token and store it locally in
|
|||
|
<em>~/.cargo/credentials</em>. Note that this token is a <em>secret</em>: do not share it
|
|||
|
with anyone else. If you do share it with anyone for any reason, you should
|
|||
|
revoke it and generate a new token on <a href="https://crates.io/">crates.io</a><!-- ignore
|
|||
|
-->.</p>
|
|||
|
<h3><a class="header" href="#adding-metadata-to-a-new-crate" id="adding-metadata-to-a-new-crate">Adding Metadata to a New Crate</a></h3>
|
|||
|
<p>Now that you have an account, let’s say you have a crate you want to publish.
|
|||
|
Before publishing, you’ll need to add some metadata to your crate by adding it
|
|||
|
to the <code>[package]</code> section of the crate’s <em>Cargo.toml</em> file.</p>
|
|||
|
<p>Your crate will need a unique name. While you’re working on a crate locally,
|
|||
|
you can name a crate whatever you’d like. However, crate names on
|
|||
|
<a href="https://crates.io/">crates.io</a><!-- ignore --> 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 on the site. If the name has been used by another crate, you will
|
|||
|
need to find another name and edit the <code>name</code> field in the <em>Cargo.toml</em> file
|
|||
|
under the <code>[package]</code> section to use the new name for publishing, like so:</p>
|
|||
|
<p><span class="filename">Filename: Cargo.toml</span></p>
|
|||
|
<pre><code class="language-toml">[package]
|
|||
|
name = "guessing_game"
|
|||
|
</code></pre>
|
|||
|
<p>Even if you’ve chosen a unique name, when you run <code>cargo publish</code> to publish
|
|||
|
the crate at this point, you’ll get a warning and then an error:</p>
|
|||
|
<pre><code class="language-text">$ cargo publish
|
|||
|
Updating registry `https://github.com/rust-lang/crates.io-index`
|
|||
|
warning: manifest has no description, license, license-file, documentation,
|
|||
|
homepage or repository.
|
|||
|
--snip--
|
|||
|
error: api errors: missing or empty metadata fields: description, license.
|
|||
|
</code></pre>
|
|||
|
<p>The reason is that 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. To rectify this error, you need to include this
|
|||
|
information in the <em>Cargo.toml</em> file.</p>
|
|||
|
<p>Add a description that is just a sentence or two, because it will appear with
|
|||
|
your crate in search results. For the <code>license</code> field, you need to give a
|
|||
|
<em>license identifier value</em>. The <a href="http://spdx.org/licenses/">Linux Foundation’s Software Package Data
|
|||
|
Exchange (SPDX)</a> lists the identifiers you can use for this value. For
|
|||
|
example, to specify that you’ve licensed your crate using the MIT License, add
|
|||
|
the <code>MIT</code> identifier:</p>
|
|||
|
<p><span class="filename">Filename: Cargo.toml</span></p>
|
|||
|
<pre><code class="language-toml">[package]
|
|||
|
name = "guessing_game"
|
|||
|
license = "MIT"
|
|||
|
</code></pre>
|
|||
|
<p>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 <code>license-file</code> to specify the name of that file instead of using the
|
|||
|
<code>license</code> key.</p>
|
|||
|
<p>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 <code>MIT OR Apache-2.0</code>. This practice
|
|||
|
demonstrates that you can also specify multiple license identifiers separated
|
|||
|
by <code>OR</code> to have multiple licenses for your project.</p>
|
|||
|
<p>With a unique name, the version, the author details that <code>cargo new</code> added
|
|||
|
when you created the crate, your description, and a license added, the
|
|||
|
<em>Cargo.toml</em> file for a project that is ready to publish might look like this:</p>
|
|||
|
<p><span class="filename">Filename: Cargo.toml</span></p>
|
|||
|
<pre><code class="language-toml">[package]
|
|||
|
name = "guessing_game"
|
|||
|
version = "0.1.0"
|
|||
|
authors = ["Your Name <you@example.com>"]
|
|||
|
edition = "2018"
|
|||
|
description = "A fun game where you guess what number the computer has chosen."
|
|||
|
license = "MIT OR Apache-2.0"
|
|||
|
|
|||
|
[dependencies]
|
|||
|
</code></pre>
|
|||
|
<p><a href="https://doc.rust-lang.org/cargo/">Cargo’s documentation</a> describes other
|
|||
|
metadata you can specify to ensure others can discover and use your crate more
|
|||
|
easily.</p>
|
|||
|
<h3><a class="header" href="#publishing-to-cratesio" id="publishing-to-cratesio">Publishing to Crates.io</a></h3>
|
|||
|
<p>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!
|
|||
|
Publishing a crate uploads a specific version to
|
|||
|
<a href="https://crates.io/">crates.io</a><!-- ignore --> for others to use.</p>
|
|||
|
<p>Be careful when publishing a crate because a publish is <em>permanent</em>. The
|
|||
|
version can never be overwritten, and the code cannot be deleted. One major
|
|||
|
goal of <a href="https://crates.io/">crates.io</a><!-- ignore --> is to act as a permanent
|
|||
|
archive of code so that builds of all projects that depend on crates from
|
|||
|
<a href="https://crates.io/">crates.io</a><!-- ignore --> 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.</p>
|
|||
|
<p>Run the <code>cargo publish</code> command again. It should succeed now:</p>
|
|||
|
<pre><code class="language-text">$ cargo publish
|
|||
|
Updating registry `https://github.com/rust-lang/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.19 secs
|
|||
|
Uploading guessing_game v0.1.0 (file:///projects/guessing_game)
|
|||
|
</code></pre>
|
|||
|
<p>Congratulations! You’ve now shared your code with the Rust community, and
|
|||
|
anyone can easily add your crate as a dependency of their project.</p>
|
|||
|
<h3><a class="header" href="#publishing-a-new-version-of-an-existing-crate" id="publishing-a-new-version-of-an-existing-crate">Publishing a New Version of an Existing Crate</a></h3>
|
|||
|
<p>When you’ve made changes to your crate and are ready to release a new version,
|
|||
|
you change the <code>version</code> value specified in your <em>Cargo.toml</em> file and
|
|||
|
republish. Use the <a href="http://semver.org/">Semantic Versioning rules</a> to decide what an
|
|||
|
appropriate next version number is based on the kinds of changes you’ve made.
|
|||
|
Then run <code>cargo publish</code> to upload the new version.</p>
|
|||
|
<h3><a class="header" href="#removing-versions-from-cratesio-with-cargo-yank" id="removing-versions-from-cratesio-with-cargo-yank">Removing Versions from Crates.io with <code>cargo yank</code></a></h3>
|
|||
|
<p>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
|
|||
|
supports <em>yanking</em> a crate version.</p>
|
|||
|
<p>Yanking a version prevents new projects from starting to depend on that version
|
|||
|
while allowing all existing projects that depend on it to continue to download
|
|||
|
and depend on that version. Essentially, a yank means that all projects with a
|
|||
|
<em>Cargo.lock</em> will not break, and any future <em>Cargo.lock</em> files generated will
|
|||
|
not use the yanked version.</p>
|
|||
|
<p>To yank a version of a crate, run <code>cargo yank</code> and specify which version you
|
|||
|
want to yank:</p>
|
|||
|
<pre><code class="language-text">$ cargo yank --vers 1.0.1
|
|||
|
</code></pre>
|
|||
|
<p>By adding <code>--undo</code> to the command, you can also undo a yank and allow projects
|
|||
|
to start depending on a version again:</p>
|
|||
|
<pre><code class="language-text">$ cargo yank --vers 1.0.1 --undo
|
|||
|
</code></pre>
|
|||
|
<p>A yank <em>does not</em> delete any code. For example, the yank feature is not
|
|||
|
intended for deleting accidentally uploaded secrets. If that happens, you must
|
|||
|
reset those secrets immediately.</p>
|
|||
|
|
|||
|
</main>
|
|||
|
|
|||
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|||
|
<!-- Mobile navigation buttons -->
|
|||
|
|
|||
|
<a rel="prev" href="ch14-01-release-profiles.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
<i class="fa fa-angle-left"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<a rel="next" href="ch14-03-cargo-workspaces.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
<i class="fa fa-angle-right"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
<div style="clear: both"></div>
|
|||
|
</nav>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
|
|||
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|||
|
|
|||
|
<a href="ch14-01-release-profiles.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|||
|
<i class="fa fa-angle-left"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<a href="ch14-03-cargo-workspaces.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|||
|
<i class="fa fa-angle-right"></i>
|
|||
|
</a>
|
|||
|
|
|||
|
</nav>
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<script type="text/javascript">
|
|||
|
window.playpen_copyable = true;
|
|||
|
</script>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|||
|
|
|||
|
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
<script src="book.js" type="text/javascript" charset="utf-8"></script>
|
|||
|
|
|||
|
<!-- Custom JS scripts -->
|
|||
|
|
|||
|
<script type="text/javascript" src="ferris.js"></script>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
</body>
|
|||
|
</html>
|