LabEx
LoginBeitreten

Veröffentlichen einer Crate auf Crates.io

Beginner

This tutorial is from open-source community. Access the source code

Einführung

Willkommen bei Publishing a Crate to Crates.io. Dieser Lab ist Teil des Rust Buchs. Du kannst deine Rust-Fähigkeiten in LabEx üben.

In diesem Lab werden wir diskutieren, wie man einen Crate auf crates.io veröffentlicht, dem Crate-Registry, das Open-Source-Code verteilt und es somit einfacher macht, deine Pakete zu finden und zu verwenden.

Ein Crate auf crates.io veröffentlichen

Wir haben Pakete von https://crates.io als Abhängigkeiten unseres Projekts verwendet, aber du kannst auch deinen Code mit anderen teilen, indem du deine eigenen Pakete veröffentliest. Das Crate-Registry bei https://crates.io verteilt den Quellcode deiner Pakete, sodass es hauptsächlich Code hostet, der Open-Source ist.

Rust und Cargo haben Funktionen, die es anderen Leuten einfacher machen, dein veröffentlichtes Package zu finden und zu verwenden. Wir werden im Folgenden einige dieser Funktionen besprechen und dann erklären, wie man ein Package veröffentlicht.

Verwirklichung nützlicher Dokumentationskommentare

Genau dokumentieren Sie Ihre Pakete, um anderen Benutzern zu helfen, zu verstehen, wie und wann sie diese verwenden können. Es lohnt sich daher, die Zeit für die Erstellung von Dokumentationen aufzuwenden. Im dritten Kapitel haben wir diskutiert, wie man Rust-Code mit zwei Schrägstrichen (//) kommentiert. Rust hat auch einen speziellen Art von Kommentar für die Dokumentation, der bequem als Dokumentationskommentar bezeichnet wird und HTML-Dokumentation erzeugt. Die HTML-Anzeige zeigt den Inhalt von Dokumentationskommentaren für öffentliche API-Elemente an, die für Programmierer von Interesse sind, die wissen möchten, wie sie Ihr Crate verwenden, im Gegensatz zu wie Ihr Crate implementiert ist.

Dokumentationskommentare verwenden drei Schrägstriche (///) anstelle von zwei und unterstützen die Markdown-Notation zur Formatierung des Textes. Platzieren Sie die Dokumentationskommentare direkt vor dem Element, das sie dokumentieren. Listing 14-1 zeigt die Dokumentationskommentare für eine add_one-Funktion in einem Crate namens my_crate.

Dateiname: src/lib.rs

/// Fügt eins zur angegebenen Zahl hinzu.
///
/// ## Beispiele
///
/// ```
/// let arg = 5;
/// let answer = my_crate::add_one(arg);
///
/// assert_eq!(6, answer);
/// ```rust
pub fn add_one(x: i32) -> i32 {
    x + 1
}

Listing 14-1: Ein Dokumentationskommentar für eine Funktion

Hier geben wir eine Beschreibung davon, was die add_one-Funktion macht, beginnen einen Abschnitt mit dem Titel Beispiele und geben dann Code, der zeigt, wie man die add_one-Funktion verwendet. Wir können die HTML-Dokumentation aus diesem Dokumentationskommentar generieren, indem wir cargo doc ausführen. Dieser Befehl führt das mit Rust verteilte rustdoc-Tool aus und legt die generierte HTML-Dokumentation im target/doc-Verzeichnis ab.

Zur Bequemlichkeit führt cargo doc --open die HTML-Erstellung für die Dokumentation Ihres aktuellen Crates (sowie die Dokumentation aller Abhängigkeiten Ihres Crates) durch und öffnet das Ergebnis in einem Webbrowser. Navigieren Sie zur add_one-Funktion, und Sie werden sehen, wie der Text in den Dokumentationskommentaren gerendert wird, wie in Abbildung 14-1 gezeigt.

Abbildung 14-1: HTML-Dokumentation für die add_one-Funktion

Allgemein verwendete Abschnitte

Wir haben im Listing 14-1 den Markdown-Überschriftentext ## Beispiele verwendet, um einen Abschnitt im HTML mit dem Titel "Beispiele" zu erstellen. Hier sind einige weitere Abschnitte, die Crate-Autoren in ihrer Dokumentation häufig verwenden:

  • Panics: Die Szenarien, in denen die dokumentierte Funktion in Panik geraten kann. Aufrufer der Funktion, die nicht möchten, dass ihr Programm in Panik gerät, sollten sicherstellen, dass sie die Funktion in diesen Situationen nicht aufrufen.
  • Fehler: Wenn die Funktion ein Result zurückgibt, kann es für die Aufrufer hilfreich sein, die Arten von Fehlern zu beschreiben, die auftreten können, und welche Bedingungen dazu führen können, dass diese Fehler zurückgegeben werden, damit sie Code schreiben können, um die verschiedenen Arten von Fehlern auf unterschiedliche Weise zu behandeln.
  • Sicherheit: Wenn die Funktion unsicher aufzurufen ist (wir diskutieren die Unsicherheit im Kapitel 19), sollte es einen Abschnitt geben, der erklärt, warum die Funktion unsicher ist und die Invarianten umfasst, die die Funktion erwartet, dass die Aufrufer einhalten.

Die meisten Dokumentationskommentare brauchen nicht alle diese Abschnitte, aber dies ist eine gute Kontrollliste, um Sie daran zu erinnern, an welchen Aspekten Ihres Codes die Benutzer interessiert sein werden.

Dokumentationskommentare als Tests

Das Hinzufügen von Codebeispielblöcken in Ihren Dokumentationskommentaren kann helfen, zu zeigen, wie Ihre Bibliothek verwendet werden kann, und dabei gibt es einen zusätzlichen Vorteil: Wenn Sie cargo test ausführen, werden die Codebeispiele in Ihrer Dokumentation als Tests ausgeführt! Nichts ist besser als Dokumentation mit Beispielen. Aber nichts ist schlimmer als Beispiele, die nicht funktionieren, weil der Code seit der Erstellung der Dokumentation geändert wurde. Wenn wir cargo test mit der Dokumentation der add_one-Funktion aus Listing 14-1 ausführen, werden wir einen Abschnitt in den Testergebnissen sehen, der wie folgt aussieht:

   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; finished in 0.27s

Nun, wenn wir die Funktion oder das Beispiel ändern, sodass das assert_eq! im Beispiel in Panik gerät und wir cargo test erneut ausführen, werden wir sehen, dass die Dokutests erkennen, dass das Beispiel und der Code nicht mehr übereinstimmen!

Kommentieren von enthaltenen Elementen

Der Dokumenationskommentar //! fügt Dokumentation zu dem Element hinzu, das die Kommentare enthält, anstatt zu den Elementen, die nach den Kommentaren stehen. Wir verwenden diese Dokumenationskommentare normalerweise innerhalb der Crate-Wurzeldatei (src/lib.rs üblicherweise) oder innerhalb eines Moduls, um die gesamte Crate oder das Modul zu dokumentieren.

Zum Beispiel, um Dokumentation hinzuzufügen, die den Zweck der my_crate-Crate beschreibt, die die add_one-Funktion enthält, fügen wir Dokumenationskommentare hinzu, die mit //! beginnen, am Anfang der src/lib.rs-Datei, wie in Listing 14-2 gezeigt.

Dateiname: src/lib.rs

//! ## Meine Crate
//!
//! `my_crate` ist eine Sammlung von Hilfsmitteln, um bestimmte
//! Berechnungen einfacher durchzuführen.

/// Fügt eins zur angegebenen Zahl hinzu.
--snip--

Listing 14-2: Dokumentation für die gesamte my_crate-Crate

Beachten Sie, dass nach der letzten Zeile, die mit //! beginnt, kein Code mehr vorhanden ist. Da wir die Kommentare mit //! statt mit /// begonnen haben, dokumentieren wir das Element, das diesen Kommentar enthält, anstatt ein Element, das diesem Kommentar folgt. In diesem Fall ist das Element die src/lib.rs-Datei, die die Crate-Wurzel ist. Diese Kommentare beschreiben die gesamte Crate.

Wenn wir cargo doc --open ausführen, werden diese Kommentare auf der Titelseite der Dokumentation für my_crate über der Liste der öffentlichen Elemente in der Crate angezeigt, wie in Abbildung 14-2 gezeigt.

Abbildung 14-2: Gerenderte Dokumentation für my_crate, einschließlich des Kommentars, der die gesamte Crate beschreibt

Dokumentationskommentare innerhalb von Elementen sind besonders nützlich für die Beschreibung von Crates und Modulen. Verwenden Sie sie, um den Gesamtzweck des Containers zu erklären, um Ihren Benutzern zu helfen, die Struktur der Crate zu verstehen.

Exportieren einer bequemen öffentlichen API mit pub use

Die Struktur Ihrer öffentlichen API ist ein wichtiger Aspekt, wenn Sie eine Crate veröffentlichen. Personen, die Ihre Crate verwenden, sind weniger vertraut mit der Struktur als Sie und können Schwierigkeiten haben, die Elemente zu finden, die sie verwenden möchten, wenn Ihre Crate eine große Modulhierarchie hat.

Im siebten Kapitel haben wir behandelt, wie man Elemente öffentlich macht, indem man das Schlüsselwort pub verwendet, und wie man Elemente in einen Gültigkeitsbereich bringt, indem man das Schlüsselwort use verwendet. Die Struktur, die Ihnen während der Entwicklung einer Crate sinnvoll erscheint, kann jedoch für Ihre Benutzer nicht sehr bequem sein. Sie möchten möglicherweise Ihre Structs in einer Hierarchie mit mehreren Ebenen organisieren, aber dann können Personen, die einen Typ verwenden möchten, den Sie tief in der Hierarchie definiert haben, Schwierigkeiten haben, herauszufinden, dass dieser Typ existiert. Sie können auch ärgerlich darüber sein, dass sie use my_crate::some_module::another_module::UsefulType; statt use my_crate::UsefulType; eingeben müssen.

Die gute Nachricht ist, dass Sie nicht umorganisieren müssen, wenn die Struktur für andere unbrauchbar ist: Stattdessen können Sie Elemente erneut exportieren, um eine öffentliche Struktur zu erstellen, die von Ihrer privaten Struktur unterschiedlich ist, indem Sie pub use verwenden. Neuexportieren nimmt ein öffentliches Element an einem Ort und macht es an einem anderen Ort öffentlich, als wäre es dort definiert.

Nehmen wir beispielsweise an, dass wir eine Bibliothek namens art für die Modellierung künstlerischer Konzepte erstellt haben. Innerhalb dieser Bibliothek befinden sich zwei Module: Ein kinds-Modul, das zwei Enums namens PrimaryColor und SecondaryColor enthält, und ein utils-Modul, das eine Funktion namens mix enthält, wie in Listing 14-3 gezeigt.

Dateiname: src/lib.rs

//! ## Kunst
//!
//! Eine Bibliothek zur Modellierung künstlerischer Konzepte.

pub mod kinds {
    /// Die primären Farben gemäß dem RYB-Farbmodell.
    pub enum PrimaryColor {
        Rot,
        Gelb,
        Blau,
    }

    /// Die sekundären Farben gemäß dem RYB-Farbmodell.
    pub enum SecondaryColor {
        Orange,
        Grün,
        Lila,
    }
}

pub mod utils {
    use crate::kinds::*;

    /// Kombiniert zwei primäre Farben in gleichen Mengen, um
    /// eine sekundäre Farbe zu erzeugen.
    pub fn mix(
        c1: PrimaryColor,
        c2: PrimaryColor,
    ) -> SecondaryColor {
        --snip--
    }
}

Listing 14-3: Eine art-Bibliothek mit Elementen, die in die Module kinds und utils organisiert sind

Abbildung 14-3 zeigt, wie die Titelseite der Dokumentation für diese Crate, die von cargo doc generiert wird, aussehen würde.

Abbildung 14-3: Titelseite der Dokumentation für art, die die Module kinds und utils auflistet

Beachten Sie, dass die Typen PrimaryColor und SecondaryColor sowie die Funktion mix nicht auf der Titelseite aufgelistet sind. Wir müssen auf kinds und utils klicken, um sie zu sehen.

Eine andere Crate, die von dieser Bibliothek abhängt, würde use-Anweisungen benötigen, die die Elemente aus art in den Gültigkeitsbereich bringen und die derzeit definierte Modulstruktur angeben. Listing 14-4 zeigt ein Beispiel einer Crate, die die Elemente PrimaryColor und mix aus der art-Crate verwendet.

Dateiname: src/main.rs

use art::kinds::PrimaryColor;
use art::utils::mix;

fn main() {
    let rot = PrimaryColor::Rot;
    let gelb = PrimaryColor::Gelb;
    mix(rot, gelb);
}

Listing 14-4: Eine Crate, die die Elemente der art-Crate mit ihrer exportierten internen Struktur verwendet

Der Autor des Codes in Listing 14-4, der die art-Crate verwendet, musste herausfinden, dass PrimaryColor im kinds-Modul und mix im utils-Modul ist. Die Modulstruktur der art-Crate ist für Entwickler, die an der art-Crate arbeiten, relevanter als für diejenigen, die sie verwenden. Die interne Struktur enthält keine nützlichen Informationen für jemanden, der verstehen möchte, wie man die art-Crate verwendet, sondern verursacht eher Verwirrung, da Entwickler, die sie verwenden, herausfinden müssen, wo sie nachzusehen ist und die Modulnamen in den use-Anweisungen angeben müssen.

Um die interne Organisation aus der öffentlichen API zu entfernen, können wir den Code der art-Crate in Listing 14-3 ändern, um pub use-Anweisungen hinzuzufügen, um die Elemente auf der obersten Ebene erneut zu exportieren, wie in Listing 14-5 gezeigt.

Dateiname: src/lib.rs

//! ## Kunst
//!
//! Eine Bibliothek zur Modellierung künstlerischer Konzepte.

pub use self::kinds::PrimaryColor;
pub use self::kinds::SecondaryColor;
pub use self::utils::mix;

pub mod kinds {
    --snip--
}

pub mod utils {
    --snip--
}

Listing 14-5: Hinzufügen von pub use-Anweisungen, um Elemente erneut zu exportieren

Die API-Dokumentation, die cargo doc für diese Crate generiert, wird jetzt die Neuerweiterungen auf der Titelseite auflisten und verlinken, wie in Abbildung 14-4 gezeigt, was es einfacher macht, die Typen PrimaryColor und SecondaryColor sowie die Funktion mix zu finden.

Abbildung 14-4: Die Titelseite der Dokumentation für art, die die Neuerweiterungen auflistet

Die Benutzer der art-Crate können immer noch die interne Struktur aus Listing 14-3 sehen und verwenden, wie in Listing 14-4 gezeigt, oder sie können die bequemere Struktur in Listing 14-5 verwenden, wie in Listing 14-6 gezeigt.

Dateiname: src/main.rs

use art::mix;
use art::PrimaryColor;

fn main() {
    --snip--
}

Listing 14-6: Ein Programm, das die erneut exportierten Elemente der art-Crate verwendet

In Fällen mit vielen geschachtelten Modulen kann das Neuerweitern der Typen auf der obersten Ebene mit pub use einen großen Unterschied im Benutzererlebnis machen. Ein weiterer häufiger Gebrauch von pub use ist es, die Definitionen einer Abhängigkeit in der aktuellen Crate erneut zu exportieren, um die Definitionen dieser Crate zum öffentlichen API Ihrer Crate zu machen.

Das Erstellen einer nützlichen öffentlichen API-Struktur ist eher eine Kunst als eine Wissenschaft, und Sie können iterieren, um die API zu finden, die am besten für Ihre Benutzer funktioniert. Die Verwendung von pub use gibt Ihnen Flexibilität bei der internen Strukturierung Ihrer Crate und trennt diese interne Struktur von der, die Sie Ihren Benutzern präsentieren. Schauen Sie sich den Code einiger von den Crates an, die Sie installiert haben, um zu sehen, ob ihre interne Struktur von ihrer öffentlichen API unterschiedlich ist.

Ein Crates.io-Konto einrichten

Bevor Sie irgendwelche Crates veröffentlichen können, müssen Sie ein Konto auf https://crates.io erstellen und einen API-Token erhalten. Um dies zu tun, besuchen Sie die Startseite auf https://crates.io und melden Sie sich über ein GitHub-Konto an. (Das GitHub-Konto ist derzeit ein Voraussetzung, aber die Website wird möglicherweise in Zukunft auch andere Möglichkeiten des Erstellens eines Kontos unterstützen.) Nachdem Sie sich angemeldet haben, besuchen Sie Ihre Kontoeinstellungen auf https://crates.io/me und erhalten Sie Ihren API-Schlüssel. Anschließend führen Sie den Befehl cargo login mit Ihrem API-Schlüssel aus, wie folgt:

cargo login abcdefghijklmnopqrstuvwxyz012345

Dieser Befehl wird Cargo über Ihren API-Token informieren und ihn lokal in ~/.cargo/credentials speichern. Beachten Sie, dass dieser Token ein Geheimnis ist: Teilen Sie ihn mit niemandem anderen. Wenn Sie ihn aus irgendeinem Grund mit jemandem teilen, sollten Sie ihn widerrufen und einen neuen Token auf https://crates.io generieren.

Hinzufügen von Metadaten zu einer neuen Crate

Angenommen, Sie haben eine Crate, die Sie veröffentlichen möchten. Bevor Sie veröffentlichen, müssen Sie einige Metadaten im Abschnitt [package] der Cargo.toml-Datei der Crate hinzufügen.

Ihre Crate muss einen eindeutigen Namen haben. Während Sie lokal an einer Crate arbeiten, können Sie eine Crate wie Sie möchten benennen. Auf https://crates.io werden jedoch Crate-Namen auf einen ersten-kommt, ersten-dient-Basis zugewiesen. Wenn ein Crate-Name bereits vergeben ist, kann niemand else eine Crate mit diesem Namen veröffentlichen. Bevor Sie versuchen, eine Crate zu veröffentlichen, suchen Sie nach dem Namen, den Sie verwenden möchten. Wenn der Name bereits verwendet wurde, müssen Sie einen anderen Namen finden und das name-Feld in der Cargo.toml-Datei unter dem Abschnitt [package] bearbeiten, um den neuen Namen für die Veröffentlichung zu verwenden, wie folgt:

Dateiname: Cargo.toml

[package]
name = "guessing_game"

Auch wenn Sie einen eindeutigen Namen gewählt haben, wenn Sie cargo publish ausführen, um die Crate zu veröffentlichen, erhalten Sie eine Warnung und dann einen Fehler:

$ cargo publish
    Updating crates.io index
warning: manifest has no description, license, license-file, documentation,
homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata
for more info.
--snip--
error: failed to publish to registry at https://crates.io

Caused by:
  the remote server responded with an error: missing or empty metadata fields:
description, license. Please see https://doc.rust-
lang.org/cargo/reference/manifest.html for how to upload metadata

Dies führt zu einem Fehler, weil Sie einige wichtige Informationen fehlen: Eine Beschreibung und eine Lizenz sind erforderlich, damit die Menschen wissen, was Ihre Crate macht und unter welchen Bedingungen sie sie verwenden können. In Cargo.toml fügen Sie eine Beschreibung hinzu, die nur ein oder zwei Sätze umfasst, da sie in den Suchergebnissen mit Ihrer Crate erscheinen wird. Für das license-Feld müssen Sie einen Lizenzbezeichnerwert angeben. Die Software Package Data Exchange (SPDX) der Linux Foundation auf http://spdx.org/licenses listet die Bezeichner, die Sie für diesen Wert verwenden können. Beispielsweise um anzugeben, dass Sie Ihre Crate unter der MIT-Lizenz lizenziert haben, fügen Sie den Bezeichner MIT hinzu:

Dateiname: Cargo.toml

[package]
name = "guessing_game"
license = "MIT"

Wenn Sie eine Lizenz verwenden möchten, die nicht in der SPDX erscheint, müssen Sie den Text dieser Lizenz in eine Datei platzieren, die Datei in Ihrem Projekt einbeziehen und dann license-file verwenden, um den Namen dieser Datei anzugeben, anstatt den license-Schlüssel zu verwenden.

Die Beratung darüber, welche Lizenz für Ihr Projekt geeignet ist, liegt außerhalb des Rahmens dieses Buches. Viele Menschen in der Rust-Community lizenzieren ihre Projekte auf die gleiche Weise wie Rust, indem sie eine doppelte Lizenz von MIT OR Apache-2.0 verwenden. Diese Praxis zeigt, dass Sie auch mehrere Lizenzbezeichner getrennt durch OR angeben können, um mehrere Lizenzen für Ihr Projekt zu haben.

Mit einem eindeutigen Namen, der Version, Ihrer Beschreibung und einer Lizenz hinzugefügt, könnte die Cargo.toml-Datei eines Projekts, das bereit zum Veröffentlichen ist, wie folgt aussehen:

Dateiname: Cargo.toml

[package]
name = "guessing_game"
version = "0.1.0"
edition = "2021"
description = "A fun game where you guess what number the
computer has chosen."
license = "MIT OR Apache-2.0"

[dependencies]

Die Dokumentation von Cargo auf https://doc.rust-lang.org/cargo beschreibt andere Metadaten, die Sie angeben können, um sicherzustellen, dass andere Ihre Crate leichter entdecken und verwenden können.

Veröffentlichen auf Crates.io

Jetzt, nachdem Sie ein Konto erstellt haben, Ihren API-Token gespeichert haben, einen Namen für Ihre Crate gewählt haben und die erforderlichen Metadaten angegeben haben, sind Sie bereit zum Veröffentlichen! Beim Veröffentlichen einer Crate wird eine bestimmte Version auf https://crates.io hochgeladen, damit andere sie verwenden können.

Achten Sie darauf, denn ein Veröffentlichung ist permanent. Die Version kann niemals überschrieben werden und der Code kann nicht gelöscht werden. Ein wichtiges Ziel von Crates.io ist es, als permanenter Codearchiv zu fungieren, damit die Builds aller Projekte, die von Crates von https://crates.io abhängen, weiterhin funktionieren. Die Erlaubnis von Versionlöschungen würde das Erreichen dieses Ziels unmöglich machen. Es gibt jedoch keine Beschränkung für die Anzahl der Crate-Versionen, die Sie veröffentlichen können.

Führen Sie den Befehl cargo publish erneut aus. Es sollte jetzt erfolgreich sein:

$ 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)

Herzlichen Glückwunsch! Sie haben jetzt Ihren Code mit der Rust-Community geteilt, und jeder kann Ihre Crate als Abhängigkeit ihres Projekts leicht hinzufügen.

Veröffentlichen einer neuen Version einer bestehenden Crate

Wenn Sie Änderungen an Ihrer Crate vorgenommen haben und bereit sind, eine neue Version zu veröffentlichen, ändern Sie den in Ihrer Cargo.toml-Datei angegebenen version-Wert und veröffentlichen Sie erneut. Verwenden Sie die Semantic Versioning-Regeln auf http://semver.org, um zu bestimmen, welche passende nächste Versionsnummer ist, basierend auf den Art der Änderungen, die Sie vorgenommen haben. Anschließend führen Sie cargo publish aus, um die neue Version hochzuladen.

Deprecieren von Versionen von Crates.io mit cargo yank

Obwohl Sie frühere Versionen einer Crate nicht entfernen können, können Sie verhindern, dass zukünftige Projekte sie als neue Abhängigkeit hinzufügen. Dies ist nützlich, wenn eine Crate-Version aus irgendeinem Grund fehlerhaft ist. In solchen Situationen unterstützt Cargo das Entfernen (Yanken) einer Crate-Version.

Das Entfernen (Yanken) einer Version verhindert, dass neue Projekte von dieser Version abhängen, während es allen bestehenden Projekten ermöglicht, die davon abhängen, weiterhin zu funktionieren. Im Wesentlichen bedeutet ein Entfernen (Yanken), dass alle Projekte mit einer Cargo.lock nicht abstürzen und dass alle zukünftig generierten Cargo.lock-Dateien die entfernte (geyankte) Version nicht verwenden werden.

Um eine Version einer Crate zu entfernen (yanken), führen Sie in dem Verzeichnis der zuvor veröffentlichten Crate cargo yank aus und geben an, welche Version Sie entfernen (yanken) möchten. Beispielsweise, wenn wir eine Crate namens guessing_game in Version 1.0.1 veröffentlicht haben und wir sie entfernen (yanken) möchten, würden wir im Projektverzeichnis von guessing_game folgendes ausführen:

$ cargo yank --vers 1.0.1
Updating crates.io index
Yank guessing_game@1.0.1

Indem Sie --undo zum Befehl hinzufügen, können Sie auch das Entfernen (Yanken) rückgängig machen und erlauben, dass Projekte wieder von einer Version abhängen:

$ cargo yank --vers 1.0.1 --undo
Updating crates.io index
Unyank guessing_game@1.0.1

Ein Entfernen (Yanken) löscht keinen Code. Es kann beispielsweise keine versehentlich hochgeladenen Geheimnisse löschen. Wenn das passiert, müssen Sie diese Geheimnisse sofort zurücksetzen.

Zusammenfassung

Herzlichen Glückwunsch! Sie haben das Lab "Veröffentlichen einer Crate auf Crates.io" abgeschlossen. Sie können in LabEx weitere Labs ausprobieren, um Ihre Fähigkeiten zu verbessern.