Cargo 常見問題

Frequently Asked Questions

常問問題

Is the plan to use GitHub as a package repository?

是否有計(jì)劃，使用 Github 作為一個(gè)包庫 ？

不，Cargo 的計(jì)劃是使用crates.io，像 NPM 或 RuuGuMes 對(duì)應(yīng) npmjs.org 和 rubygems.org。

我們計(jì)劃永遠(yuǎn)（通過些配置）支持 git 存儲(chǔ)庫作為包的來源，因?yàn)樗鼈兛梢杂糜谠缙陂_發(fā)和臨時(shí)補(bǔ)?。恿它c(diǎn)靈活性），即便人們使用主要使用注冊(cè)表作為包的來源。

Why build crates.io rather than use GitHub as a registry?

為啥，選 crates.io，而不是使用 Github 作為 注冊(cè)表 ？

我們認(rèn)為支持多種下載包的方式非常重要，包括從 GitHub 下載包，并將包復(fù)制到包本身.

也就是說，我們認(rèn)為crates.io提供了許多重要的好處，并且預(yù)計(jì)其會(huì)成為人們?cè)?Cargo 中，下載包的主要方式。

前車之鑒，Node.js 的npm和 Ruby 的bundler都支持中央注冊(cè)中心模式，和基于 Git 的模式，而大多數(shù)包都是通過生態(tài)系統(tǒng)中的注冊(cè)中心下載的，其中重要的少數(shù)包是使用基于 git 的包。

使中央注冊(cè)中心，在其他語言中流行的一些優(yōu)點(diǎn)包括:

• 可發(fā)現(xiàn)性. 中央注冊(cè)表提供了查找現(xiàn)有包的簡(jiǎn)單方式。結(jié)合標(biāo)記(版本)，這也使得注冊(cè)中心能夠提供生態(tài)系統(tǒng)的范圍信息，例如最流行或最依賴的包的列表.
• 速度. 中心注冊(cè)中心使得可以快速有效地只獲取包的元數(shù)據(jù)，然后只高效地下載已發(fā)布的包，而不會(huì)出現(xiàn)在存儲(chǔ)庫中的其他膨脹。這大大提高了依賴性解析和獲取的速度。要知道隨著依賴關(guān)系圖的擴(kuò)展，下載所有的 git 存儲(chǔ)庫會(huì)陷入困境。還要記住的是，并不是每個(gè)人都有高速、低延遲的互聯(lián)網(wǎng)連接.

Will Cargo work with C code (or other languages)?

Cargo 可與 C 語言代碼(或其他語言)一起工作嗎?

可以的!

Cargo 處理編譯 Rust 代碼，但我們知道許多 Rust 包與 C 代碼都有鏈接。我們還知道除 Rust 之外，在編譯語言方面的工具，已建立了數(shù)十年。

我們的解決方案:Cargo 允許一個(gè)包可以指定腳本(用 Rust 編寫)，其在調(diào)用rustc之前運(yùn)行。 利用 Rust 實(shí)現(xiàn)特定于平臺(tái)的配置和重構(gòu)包之間的常見構(gòu)建功能。

Can Cargo be used inside of make (or ninja, or ...)

Cargo 能被用在 make(或 ninja或...) 中嗎 ?

當(dāng)然能。盡管我們希望， Cargo 是作為頂級(jí)編譯 Rust 包的獨(dú)立方式，但我們知道有些人希望從其他構(gòu)建工具調(diào)用 Cargo。

我們已將 Cargo 設(shè)計(jì)成在這些環(huán)境中工作良好，并注意錯(cuò)誤代碼和機(jī)器可讀輸出模式等事項(xiàng)。在這些方面我們還有一些工作要做，但是在傳統(tǒng)腳本上下文中使用 Cargo 是我們從一開始就設(shè)計(jì)的，并且將繼續(xù)優(yōu)先考慮。

Does Cargo handle multi-platform packages or cross-compilation?

Cargo 是怎么平衡 多平臺(tái)或跨平臺(tái)的包的？

Rust 本身提供了基于平臺(tái)，配置代碼段的工具。Cargo 也支持特定平臺(tái)依賴關(guān)系，未來，我們計(jì)劃為每個(gè)平臺(tái)Cargo.toml支持更多的配置.

從長(zhǎng)遠(yuǎn)來看，我們正在尋找使用 Cargo 方便地跨編譯包的方法.

Does Cargo support environments, like production or test?

Cargo 有沒支持像production 或 test這樣的環(huán)境？

我們通過使用profiles來支持這樣的環(huán)境:

• 特定環(huán)境標(biāo)志(像 開發(fā)環(huán)境的 -g --opt-level=0和生產(chǎn)環(huán)境的--opt-level=3)。
• 特定環(huán)境依賴性(像 測(cè)試斷言 的hamcrest).
• 特定環(huán)境變量 #[cfg]
• 一個(gè)cargo test命令

Does Cargo work on Windows?

Windows 系統(tǒng) 呢，Cargo 能搞嗎？

沒問題!

所有提交的 Cargo 都需要通過 Windows 上的本地測(cè)試套件。但是，如果你發(fā)現(xiàn)一個(gè) Windows 問題，我們認(rèn)為它就是一個(gè) bug，所以請(qǐng)?zhí)岢鲆粋€(gè)問題.

Why do binaries have Cargo.lock in version control, but not libraries?

為啥，輸出二進(jìn)制的 Cargo 項(xiàng)目具有Cargo.lock，而單輸出庫的，就沒有？

一個(gè)Cargo.lock文件的目的，是在于成功構(gòu)建，能描述'世界'的狀態(tài)。然后，它就能用來，通過確保編譯完全相同的依賴項(xiàng)，就能跨任何機(jī)器上構(gòu)建確定性的包。

這個(gè)屬性對(duì)于，處在依賴鏈末端的應(yīng)用程序和包(二進(jìn)制文件)是最理想的。因此，建議所有二進(jìn)制文件都在其Cargo.lock內(nèi)部進(jìn)行檢查.

對(duì)于單庫來說，情況有些不同。庫不僅被庫開發(fā)人員使用，而且被庫的任何下游消費(fèi)者使用。依賴庫的用戶不會(huì)檢查庫的Cargo.lock(即使它存在)。正是如此，庫不應(yīng)該對(duì)庫的所有用戶進(jìn)行確定性地重新編譯。

如果一個(gè)庫最終被多個(gè)依賴項(xiàng)傳遞使用，那么很可能只需要該庫的一個(gè)副本(基于 semver 兼容性的版本)。如果 Cargo 使用了所有的 依賴項(xiàng)的Cargo.lock文件，那結(jié)果就是，使用庫的多個(gè)副本，甚至可能存在版本沖突。

換句話說，庫為它們的依賴項(xiàng)指定了 semver 版本，但是不用(無法)看到全部?jī)?nèi)容。只有像二進(jìn)制文件這樣的最終產(chǎn)品才需要有完整的圖，來決定應(yīng)該使用什么版本的依賴。

Can libraries use * as a version for their dependencies?

作為庫的項(xiàng)目，可以使用*作為它們的依賴的版本號(hào)嗎?

截至 2016 年 1 月 22 日，crates.io拒絕通配符*依賴約束的所有包(不只是庫).

庫是可以，但嚴(yán)格來說，他們不應(yīng)該這樣做。*版本要求，說明了"這將適用于任何版本"，而這永遠(yuǎn)不會(huì)是真的。庫應(yīng)該總是指定它們工作的范圍，即使它和"每個(gè) 1.x.y 版本"一樣。

Why Cargo.toml?

作為與 Cargo 最頻繁的交互之一，為什么要命名配置文件叫Cargo.toml的問題不時(shí)出現(xiàn)。選擇領(lǐng)先的大寫—C，是為了確保清單與目錄清單中的其他類似配置文件組合排序。對(duì)文件進(jìn)行排序時(shí)，通常將大寫字母放在小寫字母之前，確保Makefile和Cargo.toml文件會(huì)放在一起。選擇.toml結(jié)尾是強(qiáng)調(diào)文件是特定的配置文件格式.

Cargo 不允許其他名稱(如cargo.toml或Cargofile)，來強(qiáng)調(diào)如何如何容易識(shí)別 Cargo 倉庫。在歷史上，許多可能的名稱選擇都導(dǎo)致了混亂，其中一個(gè)選項(xiàng)被選擇了，而其他選項(xiàng)就被自然而然地遺忘。

How can Cargo work offline?

Cargo 能 離線 工作嗎？

Cargo 通常用于網(wǎng)絡(luò)訪問有限，或沒有網(wǎng)絡(luò)訪問的情況，如飛機(jī)、CI 環(huán)境或嵌入大型生產(chǎn)部署中。當(dāng) Cargo 試圖從網(wǎng)絡(luò)獲取資源時(shí)，用戶常常感到驚訝，因頻繁出現(xiàn) Cargo 離線工作的請(qǐng)求。

Cargo 的核心是不會(huì)試圖訪問網(wǎng)絡(luò)，除非被告知這樣做。也就是說，如果沒有來自 crates.io、git 存儲(chǔ)庫或其他網(wǎng)絡(luò)位置的箱，則 Cargo 永遠(yuǎn)不會(huì)嘗試進(jìn)行網(wǎng)絡(luò)連接。因此，如果 Cargo 試圖接觸網(wǎng)絡(luò)，那是因?yàn)樗枰@取所需的資源。

Cargo 還非常積極地緩存信息，保持最小化的網(wǎng)絡(luò)活動(dòng)量。例如，它將保證cargo build(或類似的)運(yùn)行到完成，那下一次cargo build保證不接觸網(wǎng)絡(luò)，只要Cargo.toml在此期間還沒有被修改。網(wǎng)絡(luò)的這種回避歸結(jié)為，已存在Cargo.lock，和在 lock 文件中反映了，箱子的充分緩存。如果這些組件中的任何一個(gè)丟失，那么構(gòu)建的成功就需要它們，并且必須遠(yuǎn)程獲取它們。

對(duì) Rust 1.11.0 打后的 Cargo ，可以看到新的(標(biāo)志)參數(shù)--frozen，這是它不應(yīng)該接觸網(wǎng)絡(luò)的斷言。當(dāng)傳遞給 Cargo，如果 Cargo 試圖進(jìn)行網(wǎng)絡(luò)請(qǐng)求，它將立即返回一個(gè)錯(cuò)誤。錯(cuò)誤應(yīng)該包括關(guān)于為什么進(jìn)行網(wǎng)絡(luò)請(qǐng)求(第一個(gè)地方），以幫助調(diào)試的上下文信息。注意這個(gè)標(biāo)志是不改變 Cargo 的行為，它只是斷言 Cargo 不應(yīng)該觸摸網(wǎng)絡(luò)，這作為上一個(gè)命令已完成的保證，可以相同的網(wǎng)絡(luò)活動(dòng)是不必的。

上一個(gè)命令，如cargo build