The Rust Programming Language

Crates.io-তে একটি ক্রেট পাবলিশ করা

আমরা আমাদের প্রজেক্টের ডিপেন্ডেন্সি হিসেবে crates.io-থেকে প্যাকেজ ব্যবহার করেছি, কিন্তু আপনি আপনার নিজের প্যাকেজ পাবলিশ করে অন্যদের সাথে আপনার কোড শেয়ার করতে পারেন। crates.io-এর ক্রেট রেজিস্ট্রি আপনার প্যাকেজের সোর্স কোড বিতরণ করে, তাই এটি মূলত ওপেন সোর্স কোড হোস্ট করে।

Rust এবং কার্গোর এমন কিছু ফিচার রয়েছে যা আপনার পাবলিশ করা প্যাকেজকে মানুষের খুঁজে পেতে এবং ব্যবহার করতে সহজ করে তোলে। আমরা এই ফিচারগুলোর কয়েকটি নিয়ে আলোচনা করব এবং তারপরে একটি প্যাকেজ কীভাবে পাবলিশ করতে হয় তা ব্যাখ্যা করব।

দরকারি ডকুমেন্টেশন কমেন্ট তৈরি করা

আপনার প্যাকেজগুলোকে সঠিকভাবে ডকুমেন্টেশন করা হলে অন্য ব্যবহারকারীরা জানতে পারবে কীভাবে এবং কখন সেগুলো ব্যবহার করতে হবে, তাই ডকুমেন্টেশন লেখার জন্য সময় ব্যয় করা সার্থক। অধ্যায় ৩-এ, আমরা দুটি স্ল্যাশ, // ব্যবহার করে কীভাবে Rust কোডে কমেন্ট করতে হয় তা আলোচনা করেছি। Rust-এর ডকুমেন্টেশনের জন্য একটি বিশেষ ধরনের কমেন্টও রয়েছে, যা সুবিধাজনকভাবে ডকুমেন্টেশন কমেন্ট (documentation comment) নামে পরিচিত, যা HTML ডকুমেন্টেশন তৈরি করবে। HTML ডকুমেন্টেশন পাবলিক API আইটেমগুলোর জন্য ডকুমেন্টেশন কমেন্টের বিষয়বস্তু প্রদর্শন করে, যা সেইসব প্রোগ্রামারদের জন্য তৈরি, যারা আপনার ক্রেট কীভাবে বাস্তবায়ন করা হয়েছে তার চেয়ে কীভাবে ব্যবহার করতে হয় তা জানতে আগ্রহী।

ডকুমেন্টেশন কমেন্ট দুটির পরিবর্তে তিনটি স্ল্যাশ, /// ব্যবহার করে এবং টেক্সট ফরম্যাট করার জন্য Markdown নোটেশন সমর্থন করে। যে আইটেমটি ডকুমেন্ট করা হচ্ছে তার ঠিক আগে ডকুমেন্টেশন কমেন্ট রাখুন। তালিকা ১৪-১-এ my_crate নামের একটি ক্রেটে add_one ফাংশনের জন্য ডকুমেন্টেশন কমেন্ট দেখানো হয়েছে।

/// 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
}

এখানে, আমরা add_one ফাংশনটি কী করে তার একটি বিবরণ দিচ্ছি, Examples শিরোনাম দিয়ে একটি সেকশন শুরু করছি, এবং তারপর add_one ফাংশনটি কীভাবে ব্যবহার করতে হয় তা প্রদর্শন করে এমন কোড প্রদান করছি। আমরা cargo doc চালিয়ে এই ডকুমেন্টেশন কমেন্ট থেকে HTML ডকুমেন্টেশন তৈরি করতে পারি। এই কমান্ডটি Rust-এর সাথে ডিস্ট্রিবিউট করা rustdoc টুলটি চালায় এবং জেনারেট করা HTML ডকুমেন্টেশনটি target/doc ডিরেক্টরিতে রাখে।

সুবিধার জন্য, cargo doc --open চালালে আপনার বর্তমান ক্রেটের ডকুমেন্টেশনের জন্য HTML তৈরি হবে (পাশাপাশি আপনার ক্রেটের সমস্ত ডিপেন্ডেন্সির ডকুমেন্টেশনও) এবং ফলাফলটি একটি ওয়েব ব্রাউজারে খুলবে। add_one ফাংশনে নেভিগেট করুন এবং আপনি দেখতে পাবেন ডকুমেন্টেশন কমেন্টের টেক্সট কীভাবে রেন্ডার করা হয়েছে, যেমনটি চিত্র ১৪-১-এ দেখানো হয়েছে।

চিত্র ১৪-১: add_one ফাংশনের জন্য HTML ডকুমেন্টেশন

সাধারণত ব্যবহৃত সেকশন

আমরা তালিকা ১৪-১-এ # Examples Markdown শিরোনাম ব্যবহার করে HTML-এ "Examples" শিরোনাম সহ একটি সেকশন তৈরি করেছি। এখানে আরও কিছু সেকশন রয়েছে যা ক্রেট লেখকরা সাধারণত তাদের ডকুমেন্টেশনে ব্যবহার করেন:

• Panics: যে পরিস্থিতিতে ডকুমেন্ট করা ফাংশনটি প্যানিক করতে পারে। ফাংশনের কলাররা যারা চান না তাদের প্রোগ্রাম প্যানিক করুক, তাদের নিশ্চিত করা উচিত যে তারা এই পরিস্থিতিতে ফাংশনটি কল না করে।
• Errors: যদি ফাংশনটি একটি Result রিটার্ন করে, তাহলে কী ধরনের এরর ঘটতে পারে এবং কোন শর্তে সেই এররগুলো রিটার্ন হতে পারে তা বর্ণনা করা কলারদের জন্য সহায়ক হতে পারে, যাতে তারা বিভিন্ন ধরণের এরর বিভিন্ন উপায়ে হ্যান্ডেল করার জন্য কোড লিখতে পারে।
• Safety: যদি ফাংশনটি কল করা unsafe হয় (আমরা অধ্যায় ২০-এ unsafe নিয়ে আলোচনা করব), তবে একটি সেকশন থাকা উচিত যা ব্যাখ্যা করে কেন ফাংশনটি unsafe এবং ফাংশনটি কলারদের কাছ থেকে কী কী ইনভ্যারিয়েন্ট আশা করে।

বেশিরভাগ ডকুমেন্টেশন কমেন্টের জন্য এই সমস্ত সেকশনের প্রয়োজন হয় না, তবে এটি একটি ভালো চেকলিস্ট যা আপনাকে আপনার কোডের সেই দিকগুলো মনে করিয়ে দেবে যা ব্যবহারকারীরা জানতে আগ্রহী হবে।

ডকুমেন্টেশন কমেন্টকে টেস্ট হিসাবে ব্যবহার

আপনার ডকুমেন্টেশন কমেন্টে উদাহরণ কোড ব্লক যোগ করা আপনার লাইব্রেরি কীভাবে ব্যবহার করতে হয় তা দেখাতে সাহায্য করতে পারে, এবং এটি করার একটি অতিরিক্ত বোনাস রয়েছে: cargo test চালালে আপনার ডকুমেন্টেশনের কোড উদাহরণগুলো টেস্ট হিসাবে চলবে! উদাহরণের সাথে ডকুমেন্টেশনের চেয়ে ভালো আর কিছু নেই। কিন্তু এমন উদাহরণের চেয়ে খারাপ আর কিছু নেই যা কাজ করে না কারণ ডকুমেন্টেশন লেখার পর কোড পরিবর্তন হয়েছে। যদি আমরা তালিকা ১৪-১ থেকে add_one ফাংশনের ডকুমেন্টেশন সহ cargo test চালাই, আমরা টেস্ট ফলাফলে একটি সেকশন দেখতে পাব যা এইরকম দেখায়:

   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

এখন, যদি আমরা ফাংশন বা উদাহরণটি এমনভাবে পরিবর্তন করি যাতে উদাহরণের assert_eq! প্যানিক করে, এবং আবার cargo test চালাই, আমরা দেখব যে ডক টেস্টগুলো ধরে ফেলেছে যে উদাহরণ এবং কোড একে অপরের সাথে সিঙ্কে নেই!

কন্টেইনড আইটেম কমেন্টিং

ডক কমেন্টের //! স্টাইলটি কমেন্টের পরবর্তী আইটেমের পরিবর্তে যে আইটেমটি কমেন্টগুলো ধারণ করে তার ডকুমেন্টেশন যোগ করে। আমরা সাধারণত এই ডক কমেন্টগুলো ক্রেট রুট ফাইলে (প্রচলিতভাবে src/lib.rs) বা একটি মডিউলের ভিতরে ব্যবহার করি যাতে ক্রেট বা মডিউলটিকে সামগ্রিকভাবে ডকুমেন্ট করা যায়।

উদাহরণস্বরূপ, my_crate ক্রেট, যা add_one ফাংশনটি ধারণ করে, তার উদ্দেশ্য বর্ণনা করে এমন ডকুমেন্টেশন যোগ করার জন্য, আমরা //! দিয়ে শুরু হওয়া ডকুমেন্টেশন কমেন্টগুলো src/lib.rs ফাইলের শুরুতে যোগ করি, যেমনটি তালিকা ১৪-২-এ দেখানো হয়েছে।

//! # My Crate
//!
//! `my_crate` is a collection of utilities to make performing certain
//! calculations more convenient.

/// Adds one to the number given.
// --snip--
///
/// # Examples
///
/// ```
/// let arg = 5;
/// let answer = my_crate::add_one(arg);
///
/// assert_eq!(6, answer);
/// ```
pub fn add_one(x: i32) -> i32 {
    x + 1
}

লক্ষ্য করুন, //! দিয়ে শুরু হওয়া শেষ লাইনের পরে কোনো কোড নেই। যেহেতু আমরা কমেন্টগুলো ///-এর পরিবর্তে //! দিয়ে শুরু করেছি, আমরা এই কমেন্টের পরবর্তী আইটেমের পরিবর্তে এই কমেন্ট ধারণকারী আইটেমটিকে ডকুমেন্ট করছি। এই ক্ষেত্রে, সেই আইটেমটি হল src/lib.rs ফাইল, যা ক্রেট রুট। এই কমেন্টগুলো পুরো ক্রেটকে বর্ণনা করে।

যখন আমরা cargo doc --open চালাই, তখন এই কমেন্টগুলো my_crate-এর ডকুমেন্টেশনের প্রথম পৃষ্ঠায়, ক্রেটের পাবলিক আইটেমের তালিকার উপরে প্রদর্শিত হবে, যেমনটি চিত্র ১৪-২-এ দেখানো হয়েছে।

চিত্র ১৪-২: my_crate-এর জন্য রেন্ডার করা ডকুমেন্টেশন, যা ক্রেটকে বর্ণনা করা সামগ্রিক কমেন্ট অন্তর্ভুক্ত করে

আইটেমের মধ্যে ডকুমেন্টেশন কমেন্ট ক্রেট এবং মডিউল বর্ণনা করার জন্য বিশেষভাবে কার্যকর। আপনার ব্যবহারকারীদের ক্রেটের অর্গানাইজেশন বুঝতে সাহায্য করার জন্য কন্টেইনারের সামগ্রিক উদ্দেশ্য ব্যাখ্যা করতে এগুলো ব্যবহার করুন।

pub use দিয়ে একটি সুবিধাজনক পাবলিক API এক্সপোর্ট করা

একটি ক্রেট পাবলিশ করার সময় আপনার পাবলিক API-এর গঠন একটি প্রধান বিবেচ্য বিষয়। যারা আপনার ক্রেট ব্যবহার করে তারা আপনার চেয়ে এর গঠনের সাথে কম পরিচিত এবং যদি আপনার ক্রেটের একটি বড় মডিউল হায়ারার্কি থাকে তবে তারা যে অংশগুলো ব্যবহার করতে চায় তা খুঁজে পেতে অসুবিধা হতে পারে।

অধ্যায় ৭-এ, আমরা pub কীওয়ার্ড ব্যবহার করে কীভাবে আইটেম পাবলিক করতে হয় এবং use কীওয়ার্ড দিয়ে কীভাবে স্কোপে আইটেম আনতে হয় তা আলোচনা করেছি। যাইহোক, আপনি যখন একটি ক্রেট ডেভেলপ করছেন তখন যে গঠনটি আপনার কাছে যৌক্তিক মনে হতে পারে, তা আপনার ব্যবহারকারীদের জন্য খুব সুবিধাজনক নাও হতে পারে। আপনি আপনার struct-গুলোকে একাধিক স্তরের একটি হায়ারার্কিতে সাজাতে চাইতে পারেন, কিন্তু তারপর যারা হায়ারার্কির গভীরে আপনার সংজ্ঞায়িত একটি টাইপ ব্যবহার করতে চায় তাদের জন্য সেই টাইপটি যে বিদ্যমান তা খুঁজে বের করা কঠিন হতে পারে। use my_crate::UsefulType;-এর পরিবর্তে use my_crate::some_module::another_module::UsefulType; লিখতে বাধ্য হওয়ায় তারা বিরক্তও হতে পারে।

ভালো খবর হল যে যদি গঠনটি অন্য লাইব্রেরি থেকে ব্যবহারের জন্য সুবিধাজনক না হয়, তবে আপনাকে আপনার অভ্যন্তরীণ অর্গানাইজেশন পুনর্বিন্যাস করতে হবে না: পরিবর্তে, আপনি pub use ব্যবহার করে আপনার ব্যক্তিগত গঠন থেকে ভিন্ন একটি পাবলিক গঠন তৈরি করতে আইটেমগুলো রি-এক্সপোর্ট করতে পারেন। রি-এক্সপোর্ট করা (Re-exporting) একটি স্থানের পাবলিক আইটেমকে নিয়ে অন্য একটি স্থানে পাবলিক করে, যেন এটি সেই অন্য স্থানে সংজ্ঞায়িত করা হয়েছিল।

উদাহরণস্বরূপ, ধরা যাক আমরা শৈল্পিক ধারণা মডেল করার জন্য art নামে একটি লাইব্রেরি তৈরি করেছি। এই লাইব্রেরির মধ্যে দুটি মডিউল রয়েছে: একটি kinds মডিউল যাতে PrimaryColor এবং SecondaryColor নামে দুটি enum রয়েছে এবং একটি utils মডিউল যাতে mix নামে একটি ফাংশন রয়েছে, যেমনটি তালিকা ১৪-৩-এ দেখানো হয়েছে।

//! # 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--
        unimplemented!();
    }
}

চিত্র ১৪-৩ দেখায় যে cargo doc দ্বারা তৈরি এই ক্রেটের ডকুমেন্টেশনের প্রথম পাতাটি কেমন দেখাবে।

চিত্র ১৪-৩: art-এর ডকুমেন্টেশনের প্রথম পাতা যা kinds এবং utils মডিউল তালিকাভুক্ত করে

লক্ষ্য করুন যে PrimaryColor এবং SecondaryColor টাইপগুলো প্রথম পৃষ্ঠায় তালিকাভুক্ত নয়, mix ফাংশনটিও নয়। তাদের দেখতে আমাদের kinds এবং utils এ ক্লিক করতে হবে।

এই লাইব্রেরির উপর নির্ভরশীল অন্য একটি ক্রেটের use স্টেটমেন্টের প্রয়োজন হবে যা art থেকে আইটেমগুলোকে স্কোপে আনবে, বর্তমানে সংজ্ঞায়িত মডিউল কাঠামো উল্লেখ করে। তালিকা ১৪-৪ এমন একটি ক্রেটের উদাহরণ দেখায় যা art ক্রেট থেকে PrimaryColor এবং mix আইটেম ব্যবহার করে।

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

fn main() {
    let red = PrimaryColor::Red;
    let yellow = PrimaryColor::Yellow;
    mix(red, yellow);
}

তালিকা ১৪-৪ এর কোডের লেখক, যিনি art ক্রেট ব্যবহার করছেন, তাকে বের করতে হয়েছে যে PrimaryColor kinds মডিউলে এবং mix utils মডিউলে রয়েছে। art ক্রেটের মডিউল কাঠামো art ক্রেটে কাজ করা ডেভেলপারদের জন্য বেশি প্রাসঙ্গিক, যারা এটি ব্যবহার করছে তাদের চেয়ে। অভ্যন্তরীণ কাঠামোটি art ক্রেট কীভাবে ব্যবহার করতে হয় তা বোঝার চেষ্টা করা কারো জন্য কোনো দরকারী তথ্য ধারণ করে না, বরং বিভ্রান্তি সৃষ্টি করে কারণ এটি ব্যবহারকারী ডেভেলপারদের কোথায় খুঁজতে হবে তা বের করতে হয় এবং use স্টেটমেন্টে মডিউলের নাম উল্লেখ করতে হয়।

পাবলিক API থেকে অভ্যন্তরীণ অর্গানাইজেশন অপসারণ করতে, আমরা তালিকা ১৪-৩-এর art ক্রেট কোডটি পরিবর্তন করে pub use স্টেটমেন্ট যোগ করতে পারি যাতে আইটেমগুলো টপ লেভেলে রি-এক্সপোর্ট করা যায়, যেমনটি তালিকা ১৪-৫-এ দেখানো হয়েছে।

//! # 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--
    /// 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 {
    // --snip--
    use crate::kinds::*;

    /// Combines two primary colors in equal amounts to create
    /// a secondary color.
    pub fn mix(c1: PrimaryColor, c2: PrimaryColor) -> SecondaryColor {
        SecondaryColor::Orange
    }
}

এই ক্রেটের জন্য cargo doc যে API ডকুমেন্টেশন তৈরি করবে তা এখন প্রথম পৃষ্ঠায় রি-এক্সপোর্টগুলো তালিকাভুক্ত করবে এবং লিঙ্ক করবে, যেমনটি চিত্র ১৪-৪-এ দেখানো হয়েছে, যা PrimaryColor ও SecondaryColor টাইপ এবং mix ফাংশনটিকে খুঁজে পাওয়া সহজ করে তোলে।

চিত্র ১৪-৪: art-এর ডকুমেন্টেশনের প্রথম পাতা যা রি-এক্সপোর্টগুলো তালিকাভুক্ত করে

art ক্রেট ব্যবহারকারীরা এখনও তালিকা ১৪-৩ থেকে অভ্যন্তরীণ কাঠামো দেখতে এবং ব্যবহার করতে পারেন যেমনটি তালিকা ১৪-৪-এ দেখানো হয়েছে, অথবা তারা তালিকা ১৪-৫-এর আরও সুবিধাজনক কাঠামো ব্যবহার করতে পারেন, যেমনটি তালিকা ১৪-৬-এ দেখানো হয়েছে।

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

fn main() {
    // --snip--
    let red = PrimaryColor::Red;
    let yellow = PrimaryColor::Yellow;
    mix(red, yellow);
}

যেখানে অনেকগুলো নেস্টেড মডিউল রয়েছে, সেখানে pub use দিয়ে টপ লেভেলে টাইপগুলো রি-এক্সপোর্ট করা ক্রেট ব্যবহারকারীদের অভিজ্ঞতায় একটি উল্লেখযোগ্য পার্থক্য আনতে পারে। pub use-এর আরেকটি সাধারণ ব্যবহার হল বর্তমান ক্রেটে একটি ডিপেনডেন্সির ডেফিনিশন রি-এক্সপোর্ট করা যাতে সেই ক্রেটের ডেফিনিশনগুলো আপনার ক্রেটের পাবলিক API-এর অংশ হয়ে যায়।

একটি দরকারি পাবলিক API কাঠামো তৈরি করা বিজ্ঞানের চেয়ে বেশি শিল্প, এবং আপনি আপনার ব্যবহারকারীদের জন্য সবচেয়ে ভালো কাজ করে এমন API খুঁজে বের করার জন্য পুনরাবৃত্তি করতে পারেন। pub use বেছে নেওয়া আপনাকে আপনার ক্রেট অভ্যন্তরীণভাবে কীভাবে গঠন করবেন সে সম্পর্কে নমনীয়তা দেয় এবং সেই অভ্যন্তরীণ কাঠামোকে আপনি আপনার ব্যবহারকারীদের কাছে যা উপস্থাপন করেন তা থেকে বিচ্ছিন্ন করে। আপনি ইনস্টল করেছেন এমন কিছু ক্রেটের কোড দেখুন যে তাদের অভ্যন্তরীণ কাঠামো তাদের পাবলিক API থেকে ভিন্ন কিনা।

Crates.io অ্যাকাউন্ট সেট আপ করা

আপনি কোনো ক্রেট পাবলিশ করার আগে, আপনাকে crates.io-তে একটি অ্যাকাউন্ট তৈরি করতে হবে এবং একটি API টোকেন পেতে হবে। এটি করার জন্য, crates.io-এর হোম পেজে যান এবং একটি GitHub অ্যাকাউন্টের মাধ্যমে লগ ইন করুন। (বর্তমানে GitHub অ্যাকাউন্ট একটি আবশ্যকতা, তবে ভবিষ্যতে সাইটটি অ্যাকাউন্ট তৈরির অন্যান্য উপায় সমর্থন করতে পারে।) একবার আপনি লগ ইন করলে, https://crates.io/me/-এ আপনার অ্যাকাউন্ট সেটিংসে যান এবং আপনার API কী পুনরুদ্ধার করুন। তারপর cargo login কমান্ডটি চালান এবং অনুরোধ করা হলে আপনার API কী পেস্ট করুন, এরকম:

$ cargo login
abcdefghijklmnopqrstuvwxyz012345

এই কমান্ডটি কার্গোকে আপনার API টোকেন সম্পর্কে জানাবে এবং এটি স্থানীয়ভাবে ~/.cargo/credentials.toml-এ সংরক্ষণ করবে। মনে রাখবেন যে এই টোকেনটি একটি গোপনীয় বিষয়: এটি অন্য কারো সাথে শেয়ার করবেন না। যদি আপনি কোনো কারণে এটি কারো সাথে শেয়ার করেন, তাহলে আপনার উচিত এটি প্রত্যাহার করা এবং crates.io-তে একটি নতুন টোকেন তৈরি করা।

একটি নতুন ক্রেটে মেটাডেটা যোগ করা

ধরা যাক আপনার একটি ক্রেট আছে যা আপনি পাবলিশ করতে চান। পাবলিশ করার আগে, আপনাকে ক্রেটের Cargo.toml ফাইলের [package] সেকশনে কিছু মেটাডেটা যোগ করতে হবে।

আপনার ক্রেটের একটি ইউনিক নাম প্রয়োজন হবে। আপনি যখন স্থানীয়ভাবে একটি ক্রেটে কাজ করছেন, তখন আপনি ক্রেটের যা খুশি নাম দিতে পারেন। যাইহোক, crates.io-তে ক্রেটের নাম ফার্স্ট-কাম, ফার্স্ট-সার্ভড ভিত্তিতে বরাদ্দ করা হয়। একবার একটি ক্রেটের নাম নেওয়া হয়ে গেলে, অন্য কেউ সেই নামে ক্রেট পাবলিশ করতে পারবে না। একটি ক্রেট পাবলিশ করার চেষ্টা করার আগে, আপনি যে নামটি ব্যবহার করতে চান তা সার্চ করুন। যদি নামটি ব্যবহার করা হয়ে থাকে, আপনাকে অন্য একটি নাম খুঁজে বের করতে হবে এবং পাবলিশ করার জন্য নতুন নামটি ব্যবহার করতে Cargo.toml ফাইলের [package] সেকশনের অধীনে name ফিল্ডটি এডিট করতে হবে, এভাবে:

ফাইলের নাম: Cargo.toml

[package]
name = "guessing_game"

এমনকি যদি আপনি একটি ইউনিক নাম বেছে নিয়ে থাকেন, আপনি যখন এই সময়ে ক্রেটটি পাবলিশ করার জন্য cargo publish চালান, আপনি একটি ওয়ার্নিং এবং তারপর একটি এরর পাবেন:

$ 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

এর ফলে একটি এরর হয় কারণ আপনার কিছু গুরুত্বপূর্ণ তথ্য অনুপস্থিত: একটি বিবরণ এবং লাইসেন্স প্রয়োজন যাতে লোকেরা জানতে পারে আপনার ক্রেট কী করে এবং কোন শর্তে তারা এটি ব্যবহার করতে পারে। Cargo.toml-এ, একটি বিবরণ যোগ করুন যা মাত্র এক বা দুটি বাক্য, কারণ এটি সার্চ ফলাফলে আপনার ক্রেটের সাথে প্রদর্শিত হবে। license ফিল্ডের জন্য, আপনাকে একটি লাইসেন্স আইডেন্টিফায়ার ভ্যালু দিতে হবে। লিনাক্স ফাউন্ডেশনের সফটওয়্যার প্যাকেজ ডেটা এক্সচেঞ্জ (SPDX) আপনি এই মানের জন্য ব্যবহার করতে পারেন এমন আইডেন্টিফায়ারগুলো তালিকাভুক্ত করে। উদাহরণস্বরূপ, আপনি আপনার ক্রেটকে MIT লাইসেন্স ব্যবহার করে লাইসেন্স করেছেন তা নির্দিষ্ট করতে, MIT আইডেন্টিফায়ার যোগ করুন:

ফাইলের নাম: Cargo.toml

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

আপনি যদি এমন একটি লাইসেন্স ব্যবহার করতে চান যা SPDX-এ প্রদর্শিত হয় না, আপনাকে সেই লাইসেন্সের টেক্সট একটি ফাইলে রাখতে হবে, ফাইলটি আপনার প্রজেক্টে অন্তর্ভুক্ত করতে হবে এবং তারপর license কী ব্যবহার করার পরিবর্তে সেই ফাইলের নাম নির্দিষ্ট করতে license-file ব্যবহার করতে হবে।

আপনার প্রজেক্টের জন্য কোন লাইসেন্স উপযুক্ত সে সম্পর্কে নির্দেশনা এই বইয়ের সুযোগের বাইরে। রাস্ট সম্প্রদায়ের অনেক লোক তাদের প্রজেক্টগুলোকে রাস্টের মতোই লাইসেন্স করে, MIT OR Apache-2.0-এর একটি দ্বৈত লাইসেন্স ব্যবহার করে। এই অনুশীলনটি দেখায় যে আপনি আপনার প্রজেক্টের জন্য একাধিক লাইসেন্স পেতে OR দ্বারা পৃথক করা একাধিক লাইসেন্স আইডেন্টিফায়ারও নির্দিষ্ট করতে পারেন।

একটি ইউনিক নাম, সংস্করণ, আপনার বিবরণ এবং একটি লাইসেন্স যোগ করার পরে, পাবলিশ করার জন্য প্রস্তুত একটি প্রজেক্টের Cargo.toml ফাইলটি এইরকম দেখতে হতে পারে:

ফাইলের নাম: Cargo.toml

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

[dependencies]

কার্গোর ডকুমেন্টেশন অন্যান্য মেটাডেটা বর্ণনা করে যা আপনি নির্দিষ্ট করতে পারেন যাতে অন্যরা আপনার ক্রেট আরও সহজে আবিষ্কার করতে এবং ব্যবহার করতে পারে।

Crates.io-তে পাবলিশ করা

এখন যেহেতু আপনি একটি অ্যাকাউন্ট তৈরি করেছেন, আপনার API টোকেন সংরক্ষণ করেছেন, আপনার ক্রেটের জন্য একটি নাম বেছে নিয়েছেন এবং প্রয়োজনীয় মেটাডেটা নির্দিষ্ট করেছেন, আপনি পাবলিশ করার জন্য প্রস্তুত! একটি ক্রেট পাবলিশ করা একটি নির্দিষ্ট সংস্করণ crates.io-তে আপলোড করে যাতে অন্যরা এটি ব্যবহার করতে পারে।

সাবধান থাকুন, কারণ একটি পাবলিশ স্থায়ী। সংস্করণটি কখনই ওভাররাইট করা যাবে না এবং কোডটি কিছু নির্দিষ্ট পরিস্থিতি ছাড়া ডিলিট করা যাবে না। Crates.io-এর একটি প্রধান লক্ষ্য হল কোডের একটি স্থায়ী আর্কাইভ হিসাবে কাজ করা যাতে crates.io-থেকে ক্রেটের উপর নির্ভরশীল সমস্ত প্রজেক্টের বিল্ড কাজ করতে থাকে। সংস্করণ ডিলিট করার অনুমতি দিলে সেই লক্ষ্য পূরণ করা অসম্ভব হয়ে পড়বে। যাইহোক, আপনি কতগুলো ক্রেট সংস্করণ পাবলিশ করতে পারবেন তার কোনো সীমা নেই।

cargo publish কমান্ডটি আবার চালান। এটি এখন সফল হওয়া উচিত:

$ cargo publish
    Updating crates.io index
   Packaging guessing_game v0.1.0 (file:///projects/guessing_game)
    Packaged 6 files, 1.2KiB (895.0B compressed)
   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` profile [unoptimized + debuginfo] target(s) in 0.19s
   Uploading guessing_game v0.1.0 (file:///projects/guessing_game)
    Uploaded guessing_game v0.1.0 to registry `crates-io`
note: waiting for `guessing_game 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 guessing_game v0.1.0 at registry `crates-io`

অভিনন্দন! আপনি এখন রাস্ট সম্প্রদায়ের সাথে আপনার কোড শেয়ার করেছেন, এবং যে কেউ সহজেই আপনার ক্রেটকে তাদের প্রজেক্টের একটি ডিপেনডেন্সি হিসাবে যোগ করতে পারে।

একটি বিদ্যমান ক্রেটের নতুন সংস্করণ পাবলিশ করা

আপনি যখন আপনার ক্রেটে পরিবর্তন করেছেন এবং একটি নতুন সংস্করণ রিলিজ করার জন্য প্রস্তুত, তখন আপনি আপনার Cargo.toml ফাইলে নির্দিষ্ট version-এর মান পরিবর্তন করুন এবং পুনরায় পাবলিশ করুন। আপনি কী ধরনের পরিবর্তন করেছেন তার উপর ভিত্তি করে একটি উপযুক্ত পরবর্তী সংস্করণ নম্বর কী হবে তা নির্ধারণ করতে Semantic Versioning rules ব্যবহার করুন। তারপর নতুন সংস্করণ আপলোড করতে cargo publish চালান।

cargo yank দিয়ে Crates.io থেকে সংস্করণ অপসারণ করা

যদিও আপনি একটি ক্রেটের পূর্ববর্তী সংস্করণগুলো সরাতে পারবেন না, আপনি ভবিষ্যতের যেকোনো প্রজেক্টকে নতুন ডিপেনডেন্সি হিসেবে যোগ করা থেকে বিরত রাখতে পারেন। এটি তখন কার্যকর হয় যখন একটি ক্রেট সংস্করণ কোনো না কোনো কারণে ভাঙা থাকে। এই ধরনের পরিস্থিতিতে, কার্গো একটি ক্রেট সংস্করণকে yank করা সমর্থন করে।

একটি সংস্করণকে Yank করা নতুন প্রজেক্টগুলোকে সেই সংস্করণের উপর নির্ভর করতে বাধা দেয় এবং এর উপর নির্ভরশীল সমস্ত বিদ্যমান প্রজেক্টকে চলতে দেয়। মূলত, একটি yank মানে হল যে Cargo.lock সহ সমস্ত প্রজেক্ট ভাঙবে না, এবং ভবিষ্যতে তৈরি করা কোনো Cargo.lock ফাইল yank করা সংস্করণটি ব্যবহার করবে না।

একটি ক্রেটের একটি সংস্করণ yank করতে, আপনি পূর্বে পাবলিশ করেছেন এমন ক্রেটের ডিরেক্টরিতে, cargo yank চালান এবং আপনি কোন সংস্করণটি yank করতে চান তা নির্দিষ্ট করুন। উদাহরণস্বরূপ, যদি আমরা guessing_game নামের একটি ক্রেটের ১.০.১ সংস্করণ পাবলিশ করে থাকি এবং আমরা এটিকে yank করতে চাই, guessing_game এর প্রজেক্ট ডিরেক্টরিতে আমরা চালাব:

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

কমান্ডে --undo যোগ করে, আপনি একটি yank বাতিল করতে পারেন এবং প্রজেক্টগুলোকে আবার একটি সংস্করণের উপর নির্ভর করার অনুমতি দিতে পারেন:

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

একটি yank কোনো কোড ডিলিট করে না। এটি, উদাহরণস্বরূপ, ভুলবশত আপলোড করা গোপন তথ্য ডিলিট করতে পারে না। যদি এমন হয়, তাহলে আপনাকে অবিলম্বে সেই গোপন তথ্যগুলো রিসেট করতে হবে।