Rust Programlama Dili

Crates.io’da Bir Crate Yayınlama

Projelerimizde bağımlılık olarak crates.io üzerindeki paketleri kullandık; ancak kendi paketlerinizi yayınlayarak kodunuzu başka geliştiricilerle de paylaşabilirsiniz. crates.io üzerindeki crate kayıt sistemi paketlerinizin kaynak kodunu dağıtır; dolayısıyla ağırlıklı olarak açık kaynaklı kodlara ev sahipliği yapar.

Rust ve Cargo, yayınladığınız paketin başkaları tarafından daha kolay keşfedilmesini ve kullanılmasını sağlayan çeşitli özellikler sunar. Önce bu özelliklerden bazılarını ele alacak, ardından bir paketin nasıl yayınlanacağını adım adım açıklayacağız.

Yararlı Belgelendirme Yorumları Yazma

Paketlerinizi doğru ve eksiksiz biçimde belgelendirmek, diğer kullanıcıların onları ne zaman ve nasıl kullanacağını anlamasına yardımcı olur; bu nedenle belgelendirme yazmaya zaman ayırmaya değer. Bölüm 3’te iki eğik çizgi (//) kullanarak Rust koduna nasıl yorum ekleneceğini görmüştük. Rust’ta ayrıca HTML belgelendirmesi üreten ve amacına uygun biçimde belgelendirme yorumu (documentation comment) olarak adlandırılan özel bir yorum türü de vardır. Üretilen HTML, açık API öğelerine yazılmış belgelendirme yorumlarının içeriğini gösterir ve crate’inizin içeride nasıl uygulandığıyla değil, nasıl kullanılacağıyla ilgilenen programcılara yöneliktir.

Belgelendirme yorumları iki yerine üç eğik çizgi (///) kullanır ve metni biçimlendirmek için Markdown sözdizimini destekler. Belgelendirme yorumlarını, belgeledikleri öğenin hemen üstüne yerleştirin. Liste 14-1, benim_crate adlı bir crate içinde yer alan bir_ekle fonksiyonu için yazılmış belgelendirme yorumlarını göstermektedir.

/// Verilen sayıya bir ekler.
///
/// # Örnekler
///
/// ```
/// let girdi = 5;
/// let yanit = benim_crate::bir_ekle(girdi);
///
/// assert_eq!(6, yanit);
/// ```
pub fn bir_ekle(x: i32) -> i32 {
    x + 1
}

Burada bir_ekle fonksiyonunun ne yaptığını açıklıyor, Örnekler başlığıyla bir bölüm başlatıyor ve bir_ekle fonksiyonunun nasıl kullanılacağını gösteren örnek kodu paylaşıyoruz. Bu belgelendirme yorumundan HTML belgelendirmesi üretmek için cargo doc komutunu çalıştırabiliriz. Bu komut, Rust ile birlikte dağıtılan rustdoc aracını çalıştırır ve üretilen HTML dosyalarını target/doc dizinine yerleştirir.

Kolaylık sağlaması açısından cargo doc --open komutunu çalıştırmak, mevcut crate’inizin (ve tüm crate bağımlılıklarınızın) HTML belgelendirmesini derleyip sonucu doğrudan web tarayıcınızda açar. bir_ekle fonksiyonuna gittiğinizde, belgelendirme yorumlarındaki metnin Şekil 14-1’deki gibi işlendiğini görürsünüz.

Şekil 14-1: bir_ekle (add_one) fonksiyonu için üretilen HTML belgelendirmesi

Sık Kullanılan Bölümler

Liste 14-1’de HTML çıktısında “Örnekler” (Examples) başlıklı bir bölüm oluşturmak için # Örnekler Markdown başlığını kullandık. Crate yazarlarının belgelendirmelerinde sıkça kullandığı diğer standart bölümler şunlardır:

• Panics (Panik Durumları): Belgelenen fonksiyonun hangi senaryolarda panikleyebileceğini açıklar. Programlarının paniklemesini istemeyen çağıranlar, fonksiyonu bu durumlarda çağırmadıklarından emin olmalıdır.
• Errors (Hatalar): Fonksiyon bir Result döndürüyorsa, oluşabilecek hata türlerini ve hangi koşulların bu hataların döndürülmesine yol açabileceğini açıklamak çağıranlara büyük kolaylık sağlar; böylece farklı hata türlerini farklı şekillerde ele alan kodlar yazabilirler.
• Safety (Güvenlik): Fonksiyonu çağırmak unsafe ise (güvenli olmayan kodu Bölüm 20’de ele alacağız), fonksiyonun neden unsafe olduğunu açıklayan ve çağıranların sağlamasını beklediği değişmez koşulları (invariants) kapsayan bir bölüm bulunmalıdır.

Çoğu belgelendirme yorumunda bu bölümlerin tümüne ihtiyaç duyulmaz; ancak bu liste, kullanıcıların kodunuz hakkında bilmek isteyeceği yönleri size hatırlatan iyi bir kontrol listesidir.

Belgelendirme Yorumlarını Test Olarak Kullanma

Belgelendirme yorumlarınıza örnek kod blokları eklemek, kütüphanenizin nasıl kullanılacağını göstermenin yanı sıra çok değerli bir ek avantaj sağlar: cargo test komutunu çalıştırdığınızda, belgelendirmenizdeki kod örnekleri test olarak çalıştırılır! Örneklerle desteklenen bir belgelendirmeden daha iyisi yoktur; ancak belgelendirme yazıldıktan sonra kod değiştiği için artık çalışmayan örneklerden daha kötüsü de yoktur. Liste 14-1’deki bir_ekle fonksiyonunun belgelendirmesiyle cargo test çalıştırırsak test sonuçlarında şuna benzer bir bölüm görürüz:

   Doc-tests benim_crate

running 1 test
test src/lib.rs - bir_ekle (line 5) ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.27s

Şimdi fonksiyonu ya da örneği, örnekteki assert_eq! makrosunun paniklemesine yol açacak şekilde değiştirip cargo test komutunu yeniden çalıştırırsak, belge testlerinin örnek ile kod arasındaki uyumsuzluğu anında yakaladığını görürüz!

/// # Örnekler
///
/// ```
/// let sayi: i32 = "42".parse()?;
/// assert_eq!(sayi, 42);
/// # Ok::<(), std::num::ParseIntError>(())
/// ```

Kapsayıcı Öğeyi Belgeleyen Yorumlar

//! biçimindeki belgelendirme yorumları, yorumun ardından gelen öğelere değil, yorumu içeren öğeye belgelendirme ekler. Bu belgelendirme yorumlarını genellikle crate kök dosyasında (geleneksel olarak src/lib.rs) veya bir modülün içinde, crate’i ya da modülü bir bütün olarak belgelendirmek için kullanırız.

Örneğin bir_ekle fonksiyonunu barındıran benim_crate crate’inin amacını açıklayan bir belgelendirme eklemek için, Liste 14-2’de gösterildiği gibi src/lib.rs dosyasının başına //! ile başlayan belgelendirme yorumları yazarız.

//! # Benim Crate'im
//!
//! `benim_crate`, belirli hesaplamaları yapmayı daha kullanışlı hale getiren
//! yardımcı araçların bir koleksiyonudur.

/// Verilen sayıya bir ekler.
// --snip--
///
/// # Örnekler
///
/// ```
/// let girdi = 5;
/// let yanit = benim_crate::bir_ekle(girdi);
///
/// assert_eq!(6, yanit);
/// ```
pub fn bir_ekle(x: i32) -> i32 {
    x + 1
}

//! ile başlayan son satırdan sonra herhangi bir kod gelmediğine dikkat edin. Yorumları /// yerine //! ile başlattığımız için, bu yorumu izleyen bir öğeyi değil, bu yorumu barındıran öğeyi belgelendiriyoruz. Bu örnekte söz konusu öğe, crate kökü olan src/lib.rs dosyasıdır. Bu yorumlar crate’in tamamını açıklar.

cargo doc --open komutunu çalıştırdığımızda bu yorumlar, Şekil 14-2’de gösterildiği gibi benim_crate belgelendirmesinin ana sayfasında, crate içindeki açık öğeler listesinin hemen üstünde görüntülenir.

Öğelerin içinde yer alan belgelendirme yorumları özellikle crate’leri ve modülleri açıklamak için çok yararlıdır. Kapsayıcının genel amacını anlatmak ve kullanıcılarınızın crate organizasyonunu anlamasına yardımcı olmak için bunları kullanabilirsiniz.

Şekil 14-2: Crate’i bir bütün olarak açıklayan yorumu da içeren benim_crate (my_crate) belgelendirmesi

Kullanışlı Bir Açık API Dışa Aktarma

Bir crate yayınlarken açık API’nizin yapısı büyük önem taşır. Crate’inizi kullanan kişiler modül yapısına sizin kadar aşina değildir; dolayısıyla crate’iniz geniş bir modül hiyerarşisine sahipse kullanmak istedikleri parçaları bulmakta zorlanabilirler.

Bölüm 7’de pub anahtar kelimesiyle öğeleri nasıl açık hâle getireceğimizi ve use anahtar kelimesiyle öğeleri nasıl kapsama dahil edeceğimizi ele almıştık. Ancak bir crate geliştirirken size mantıklı gelen iç yapı, kullanıcılarınız için pek kullanışlı olmayabilir. Struct’larınızı birden fazla katmandan oluşan bir hiyerarşi içinde düzenlemek isteyebilirsiniz; fakat bu durumda hiyerarşinin derinliklerinde tanımladığınız bir türü kullanmak isteyen kişiler, o türün var olduğunu keşfetmekte bile güçlük çekebilir. Ayrıca use benim_crate::FaydaliTur; yazmak yerine use benim_crate::bir_modul::baska_modul::FaydaliTur; yazmak zorunda kalmak da can sıkıcı olabilir.

İyi haber şu ki bu yapı, crate’inizi başka bir kütüphaneden kullanacak kişiler için kullanışlı değilse iç organizasyonunuzu değiştirmek zorunda değilsiniz: Bunun yerine pub use kullanarak öğeleri yeniden dışa aktarabilir ve gizli iç yapınızdan farklı bir açık API yapısı oluşturabilirsiniz. Yeniden dışa aktarma (re-exporting), bir konumdaki açık bir öğeyi alır ve sanki diğer konumda tanımlanmış gibi başka bir konumda da açık hâle getirir.

Örneğin sanatsal kavramları modellemek üzere sanat adında bir kütüphane oluşturduğumuzu varsayalım. Bu kütüphanenin içinde Liste 14-3’te gösterildiği gibi iki modül bulunuyor: BirincilRenk ve IkincilRenk adlı iki enum içeren bir turler modülü ile karistir adlı bir fonksiyon içeren bir yardimcilar modülü.

//! # Sanat
//!
//! Sanatsal kavramları modellemek için bir kütüphane.

pub mod turler {
    /// RYB renk modeline göre birincil renkler.
    pub enum BirincilRenk {
        Kirmizi,
        Sari,
        Mavi,
    }

    /// RYB renk modeline göre ikincil renkler.
    pub enum IkincilRenk {
        Turuncu,
        Yesil,
        Mor,
    }
}

pub mod yardimcilar {
    use crate::turler::*;

    /// İki birincil rengi eşit miktarda birleştirerek
    /// bir ikincil renk oluşturur.
    pub fn karistir(renk1: BirincilRenk, renk2: BirincilRenk) -> IkincilRenk {
        // --snip--
        let _ = (renk1, renk2);
        unimplemented!();
    }
}

Şekil 14-3, cargo doc tarafından bu crate için üretilen belgelendirmenin ana sayfasının nasıl görüneceğini göstermektedir.

Şekil 14-3: sanat (art) belgelendirmesinin turler (kinds) ve yardimcilar (utils) modüllerini listeleyen ana sayfası

BirincilRenk ve IkincilRenk türlerinin ana sayfada listelenmediğine, aynı şekilde karistir fonksiyonunun da burada yer almadığına dikkat edin. Onları görebilmek için turler ve yardimcilar bağlantılarına tıklamamız gerekir.

Bu kütüphaneye bağımlı olan başka bir crate’in, sanat içindeki öğeleri kapsama dahil etmek için mevcut modül yapısını açıkça belirten use deyimlerine ihtiyacı olacaktır. Liste 14-4, sanat crate’inden BirincilRenk ve karistir öğelerini kullanan bir crate örneğini göstermektedir.

use sanat::turler::BirincilRenk;
use sanat::yardimcilar::karistir;

fn main() {
    let kirmizi = BirincilRenk::Kirmizi;
    let sari = BirincilRenk::Sari;
    karistir(kirmizi, sari);
}

sanat crate’ini kullanan Liste 14-4’teki kodun yazarı, BirincilRenk türünün turler modülünde ve karistir fonksiyonunun yardimcilar modülünde yer aldığını bulmak zorunda kalmıştır. sanat crate’inin modül yapısı, bu crate’i kullananlardan çok onun üzerinde çalışan geliştiricileri ilgilendirir. İç yapı, sanat crate’inin nasıl kullanılacağını anlamaya çalışan biri için yararlı bir bilgi taşımaz; aksine geliştiricilerin nereye bakacaklarını bulmak ve use deyimlerinde modül adlarını belirtmek zorunda kalmaları nedeniyle kafa karışıklığına yol açar.

İç organizasyonu açık API’den soyutlamak için Liste 14-3’teki sanat crate’i kodunu değiştirip Liste 14-5’te gösterildiği gibi öğeleri en üst düzeyde yeniden dışa aktaran pub use deyimleri ekleyebiliriz.

//! # Sanat
//!
//! Sanatsal kavramları modellemek için bir kütüphane.

pub use self::turler::BirincilRenk;
pub use self::turler::IkincilRenk;
pub use self::yardimcilar::karistir;

pub mod turler {
    // --snip--
    /// RYB renk modeline göre birincil renkler.
    pub enum BirincilRenk {
        Kirmizi,
        Sari,
        Mavi,
    }

    /// RYB renk modeline göre ikincil renkler.
    pub enum IkincilRenk {
        Turuncu,
        Yesil,
        Mor,
    }
}

pub mod yardimcilar {
    // --snip--
    use crate::turler::*;

    /// İki birincil rengi eşit miktarda birleştirerek
    /// bir ikincil renk oluşturur.
    pub fn karistir(renk1: BirincilRenk, renk2: BirincilRenk) -> IkincilRenk {
        let _ = (renk1, renk2);
        IkincilRenk::Turuncu
    }
}

cargo doc aracının bu crate için ürettiği API belgelendirmesi artık yeniden dışa aktarımları Şekil 14-4’te gösterildiği gibi ana sayfada listeleyecek ve bağlantılayacaktır; böylece BirincilRenk ve IkincilRenk türleri ile karistir fonksiyonunu bulmak çok daha kolay hâle gelecektir.

Şekil 14-4: Yeniden dışa aktarımları listeleyen sanat (art) belgelendirmesinin ana sayfası

sanat crate’inin kullanıcıları isterlerse Liste 14-3’teki iç yapıyı Liste 14-4’te gösterildiği biçimde görmeye ve kullanmaya devam edebilir, isterlerse Liste 14-6’da gösterildiği gibi Liste 14-5’teki daha kullanışlı yapıyı tercih edebilirler.

use sanat::BirincilRenk;
use sanat::karistir;

fn main() {
    // --snip--
    let kirmizi = BirincilRenk::Kirmizi;
    let sari = BirincilRenk::Sari;
    karistir(kirmizi, sari);
}

Çok sayıda iç içe modülün bulunduğu durumlarda, türleri pub use ile en üst düzeyde yeniden dışa aktarmak crate’i kullanan kişilerin deneyiminde büyük fark yaratabilir. pub use deyiminin bir diğer yaygın kullanım alanı ise bir bağımlılığın tanımlarını mevcut crate içinde yeniden dışa aktararak söz konusu crate’in tanımlarını kendi crate’inizin açık API’sinin bir parçası hâline getirmektir.

Kullanışlı bir açık API yapısı oluşturmak bilimden çok bir sanattır ve kullanıcılarınız için en iyi çalışan API’yi bulmak üzere zaman içinde iyileştirmeler yapabilirsiniz. pub use kullanmak, crate’inizi içeride nasıl yapılandıracağınız konusunda size esneklik kazandırır ve bu iç yapıyı kullanıcılarınıza sunduğunuz arayüzden ayırır. İç yapılarının açık API’lerinden farklı olup olmadığını görmek için kurduğunuz bazı crate’lerin kaynak kodlarını inceleyebilirsiniz.

Crates.io Hesabı Oluşturma

Herhangi bir crate yayınlayabilmeniz için önce crates.io üzerinde bir hesap oluşturmanız ve bir API belirteci (API token) almanız gerekir. Bunun için crates.io ana sayfasını ziyaret edin ve bir GitHub hesabıyla oturum açın. (GitHub hesabı şu an için zorunludur, ancak site gelecekte hesap oluşturmak için başka yöntemleri de destekleyebilir.) Oturum açtıktan sonra https://crates.io/me/ adresindeki hesap ayarlarınıza gidin ve API belirtecinizi alın. Ardından cargo login komutunu çalıştırın ve istendiğinde API belirtecinizi şu şekilde yapıştırın:

$ cargo login
abcdefghijklmnopqrstuvwxyz012345

Bu komut Cargo’yu API belirtecinizden haberdar eder ve onu yerel olarak ~/.cargo/credentials.toml dosyasında saklar. Bu belirtecin gizli bir bilgi olduğunu unutmayın: Başka hiç kimseyle paylaşmayın. Herhangi bir nedenle birisiyle paylaşırsanız, belirteci derhal iptal etmeli ve crates.io üzerinde yeni bir belirteç oluşturmalısınız.

Yeni Bir Crate’e Meta Veri Ekleme

Yayınlamak istediğiniz bir crate’iniz olduğunu düşünelim. Yayınlamadan önce crate’in Cargo.toml dosyasındaki [package] bölümüne bazı meta veriler eklemeniz gerekir.

Crate’inizin benzersiz bir adı olmalıdır. Yerelde bir crate üzerinde çalışırken crate’e dilediğiniz adı verebilirsiniz. Ancak crates.io üzerindeki crate adları “ilk gelen alır” ilkesine göre tahsis edilir. Bir crate adı alındıktan sonra başka hiç kimse o adla bir crate yayınlayamaz. Bir crate yayınlamaya çalışmadan önce kullanmak istediğiniz adı sitede aratın. Ad daha önce kullanılmışsa başka bir ad bulmanız ve yayınlamak üzere yeni adı kullanmak için Cargo.toml dosyasındaki [package] bölümünün altında yer alan name alanını şu şekilde düzenlemeniz gerekir:

Dosya adı: Cargo.toml

[package]
name = "tahmin_oyunu"

Benzersiz bir ad seçmiş olsanız bile, bu aşamada crate’i yayınlamak için cargo publish komutunu çalıştırdığınızda önce bir uyarı, ardından bir hata alırsınız:

$ 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 (status 400 Bad Request): missing or empty metadata fields: description, license. Please see https://doc.rust-lang.org/cargo/reference/manifest.html for more information on configuring these fields

Bazı kritik bilgiler eksik olduğu için bu işlem hatayla sonuçlanır: İnsanların crate’inizin ne işe yaradığını ve onu hangi koşullar altında kullanabileceklerini bilmeleri için bir açıklama (description) ve bir lisans (license) alanı zorunludur. Cargo.toml dosyasına, arama sonuçlarında crate’inizle birlikte görüneceği için yalnızca bir iki cümleden oluşan kısa bir açıklama ekleyin. license alanı için bir lisans tanımlayıcı değeri vermeniz gerekir. Linux Foundation’ın Software Package Data Exchange (SPDX) standardı, bu değer için kullanabileceğiniz tanımlayıcıları listeler. Örneğin crate’inizi MIT Lisansı ile lisansladığınızı belirtmek için MIT tanımlayıcısını ekleyin:

Dosya adı: Cargo.toml

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

SPDX listesinde yer almayan bir lisans kullanmak istiyorsanız, o lisansın metnini bir dosyaya yerleştirmeli, dosyayı projenize dahil etmeli ve license anahtarı yerine o dosyanın adını belirtmek üzere license-file alanını kullanmalısınız.

Projeniz için hangi lisansın uygun olduğuna dair rehberlik bu kitabın kapsamı dışındadır. Rust topluluğundaki pek çok kişi, projelerini Rust ile aynı şekilde MIT OR Apache-2.0 ikili lisansını kullanarak lisanslar. Bu uygulama, projenizde birden fazla lisansa sahip olmak için OR ile ayrılmış birden çok lisans tanımlayıcısı belirtebileceğinizi de gösterir.

Benzersiz bir ad, sürüm numarası, açıklama ve lisans eklendiğinde, yayınlanmaya hazır bir projenin Cargo.toml dosyası şöyle görünebilir:

Dosya adı: Cargo.toml

[package]
name = "tahmin_oyunu"
version = "0.1.0"
edition = "2024"
description = "Bilgisayarın seçtiği sayıyı tahmin ettiğiniz eğlenceli bir oyun."
license = "MIT OR Apache-2.0"

[dependencies]

Cargo belgeleri, başkalarının crate’inizi daha kolay keşfedip kullanabilmesini sağlamak için belirtebileceğiniz diğer meta verileri de ayrıntılı olarak açıklar.

Crates.io’da Yayınlama

Artık bir hesap oluşturduğunuza, API belirtecinizi kaydettiğinize, crate’iniz için bir ad seçtiğinize ve gerekli meta verileri belirttiğinize göre yayınlamaya hazırsınız! Bir crate yayınlamak, belirli bir sürümü başkalarının kullanabilmesi için crates.io üzerine yükler.

Dikkatli olun, çünkü yayınlama işlemi kalıcıdır. Bir sürümün üzerine asla yazılamaz ve belirli istisnai durumlar dışında kod silinemez. Crates.io’nun en önemli hedeflerinden biri, crates.io üzerindeki crate’lere bağımlı olan tüm projelerin derlemelerinin gelecekte de çalışmaya devam etmesi için kalıcı bir kod arşivi görevi görmektir. Sürümlerin silinmesine izin vermek bu hedefin gerçekleştirilmesini imkânsız kılardı. Öte yandan yayınlayabileceğiniz crate sürümlerinin sayısında herhangi bir üst sınır yoktur.

cargo publish komutunu tekrar çalıştırın. Bu kez başarılı olması gerekir:

$ cargo publish
    Updating crates.io index
   Packaging tahmin_oyunu v0.1.0 (file:///projects/tahmin_oyunu)
    Packaged 6 files, 1.2KiB (895.0B compressed)
   Verifying tahmin_oyunu v0.1.0 (file:///projects/tahmin_oyunu)
   Compiling tahmin_oyunu v0.1.0
(file:///projects/tahmin_oyunu/target/package/tahmin_oyunu-0.1.0)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.19s
   Uploading tahmin_oyunu v0.1.0 (file:///projects/tahmin_oyunu)
    Uploaded tahmin_oyunu v0.1.0 to registry `crates-io`
note: waiting for `tahmin_oyunu v0.1.0` to be available at registry
`crates-io`.
You may press ctrl-c to skip waiting; the crate should be available shortly.
   Published tahmin_oyunu v0.1.0 at registry `crates-io`

Tebrikler! Artık kodunuzu Rust topluluğuyla paylaştınız ve isteyen herkes crate’inizi kendi projesine kolayca bağımlılık olarak ekleyebilir.

Var Olan Bir Crate’in Yeni Sürümünü Yayınlama

Crate’inizde değişiklikler yaptığınızda ve yeni bir sürüm yayınlamaya hazır olduğunuzda, Cargo.toml dosyanızda belirtilen version değerini değiştirip yeniden yayınlarsınız. Yaptığınız değişikliklerin türüne göre bir sonraki uygun sürüm numarasının ne olacağına karar vermek için Semantik Sürümleme kurallarını kullanın. Ardından yeni sürümü yüklemek için cargo publish komutunu çalıştırın.

Crates.io’da Sürümleri Kullanımdan Kaldırma

Bir crate’in önceki sürümlerini silemeseniz de gelecekteki projelerin onları yeni bir bağımlılık olarak eklemesini engelleyebilirsiniz. Bu özellik, bir crate sürümü herhangi bir nedenle kusurlu çıktığında oldukça işe yarar. Böyle durumlarda Cargo, bir crate sürümünü geri çekmeyi (yanking) destekler.

Bir sürümü geri çekmek (yank), mevcut bağımlı projelerin çalışmaya devam etmesine izin verirken yeni projelerin o sürüme bağımlı olmasını engeller. Özünde geri çekme işlemi, hâlihazırda bir Cargo.lock dosyasına sahip olan tüm projelerin bozulmayacağı, ancak gelecekte üretilecek yeni Cargo.lock dosyalarının geri çekilen bu sürümü kullanmayacağı anlamına gelir.

Bir crate’in belirli bir sürümünü geri çekmek için, daha önce yayınladığınız crate’in dizininde cargo yank komutunu çalıştırır ve hangi sürümü geri çekmek istediğinizi belirtirsiniz. Örneğin tahmin_oyunu adlı bir crate’in 1.0.1 sürümünü yayınladıysak ve onu geri çekmek istiyorsak, tahmin_oyunu proje dizininde şu komutu çalıştırırız:

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

Komuta --undo seçeneğini ekleyerek bir geri çekme işlemini iptal edebilir ve projelerin ilgili sürüme yeniden bağımlı olmasına izin verebilirsiniz:

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

Geri çekme işlemi hiçbir kodu silmez. Örneğin yanlışlıkla yüklenmiş gizli anahtarları veya parolaları ortadan kaldıramaz. Böyle bir durum yaşanırsa söz konusu gizli bilgileri derhal sıfırlamanız ve yenilemeniz gerekir.