Cargo 常見問題

Frequently Asked Questions

常問問題

Is the plan to use GitHub as a package repository?

是否有計劃，使用 Github 作為一個包庫 ？

不，Cargo 的計劃是使用crates.io，像 NPM 或 RuuGuMes 對應 npmjs.org 和 rubygems.org。

我們計劃永遠（通過些配置）支持 git 存儲庫作為包的來源，因為它們可以用于早期開發(fā)和臨時補?。恿它c靈活性），即便人們使用主要使用注冊表作為包的來源。

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

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

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

也就是說，我們認為crates.io提供了許多重要的好處，并且預計其會成為人們在 Cargo 中，下載包的主要方式。

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

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

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

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

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

可以的!

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

我們的解決方案:Cargo 允許一個包可以指定腳本(用 Rust 編寫)，其在調用rustc之前運行。 利用 Rust 實現特定于平臺的配置和重構包之間的常見構建功能。

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

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

當然能。盡管我們希望， Cargo 是作為頂級編譯 Rust 包的獨立方式，但我們知道有些人希望從其他構建工具調用 Cargo。

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

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

Cargo 是怎么平衡 多平臺或跨平臺的包的？

Rust 本身提供了基于平臺，配置代碼段的工具。Cargo 也支持特定平臺依賴關系，未來，我們計劃為每個平臺Cargo.toml支持更多的配置.

從長遠來看，我們正在尋找使用 Cargo 方便地跨編譯包的方法.

Does Cargo support environments, like production or test?

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

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

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

Does Cargo work on Windows?

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

沒問題!

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

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

為啥，輸出二進制的 Cargo 項目具有Cargo.lock，而單輸出庫的，就沒有？

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

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

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

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

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

Can libraries use * as a version for their dependencies?

作為庫的項目，可以使用*作為它們的依賴的版本號嗎?

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

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

Why Cargo.toml?

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

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

How can Cargo work offline?

Cargo 能 離線 工作嗎？

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

Cargo 的核心是不會試圖訪問網絡，除非被告知這樣做。也就是說，如果沒有來自 crates.io、git 存儲庫或其他網絡位置的箱，則 Cargo 永遠不會嘗試進行網絡連接。因此，如果 Cargo 試圖接觸網絡，那是因為它需要獲取所需的資源。

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

對 Rust 1.11.0 打后的 Cargo ，可以看到新的(標志)參數--frozen，這是它不應該接觸網絡的斷言。當傳遞給 Cargo，如果 Cargo 試圖進行網絡請求，它將立即返回一個錯誤。錯誤應該包括關于為什么進行網絡請求(第一個地方），以幫助調試的上下文信息。注意這個標志是不改變 Cargo 的行為，它只是斷言 Cargo 不應該觸摸網絡，這作為上一個命令已完成的保證，可以相同的網絡活動是不必的。

上一個命令，如cargo build