Использование Cargo.lock для эффективного управления и извлечения версий зависимостей в моих ящиках

Мое рабочее пространство выглядит так:

workspace
     |--other_crate <== existing crate relying on tokio
         |-- Cargo.toml
     |--my_crate <== this is a new crate called using "cargo new --lib"
         |-- Cargo.toml
     |--Cargo.lock
     |--Cargo.toml

Я хочу добавить эту зависимость от Cargo.lock в свой новый ящик:

[[package]]
name = "tokio"
version = "1.14.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b9d0183f6f6001549ab68f8c7585093bb732beefbcf6d23a10b9b95c73a1dd49"
dependencies = [
...
]

Я бы хотел, чтобы my_crate всегда полагался на ту же версию tokio, что и other_crate, как лучше всего это сделать? Я предполагаю, что Cargo.lock является решением для этого, но не так много документации о том, как это сделать. Другими словами, есть ли в my_crate/Cargo.toml такое решение:

...
[dependencies]
tokio = {// refer to Cargo.lock's tokio entry and use it}
...

В настоящее время я просто вручную просматриваю запись Cargo.lock и вручную копирую версию. Однако, если у меня есть N ящиков, использующих одну и ту же запись, обеспечение согласованности версий (всякий раз, когда Cargo.lock необходимо обновить) будет непосильной работой...

Зачем тебе такое?

Chayim Friedman 30.03.2023 11:29
Почему Python в конце концов умрет
Почему Python в конце концов умрет
Последние 20 лет были действительно хорошими для Python. Он прошел путь от "просто языка сценариев" до основного языка, используемого для написания...
0
1
70
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я чувствую, что здесь есть несколько недоразумений.

Во-первых, Cargo.toml — официальное описание вашего пакета. Cargo.lock является чисто дополнительным. Таким образом, нет механизма полагаться на последнее; если бы это было возможно, была бы циклическая логика, в которой .toml полагается на что-то из файла блокировки, но файлу блокировки для работы требуется .toml. Представьте, если бы вы захотели регенерировать файл блокировки в своем сценарии, не было бы основы для того, какой версией должна быть зависимость от tokio.

Во-вторых, Cargo.lock уже обеспечивает использование одной версии для совместимых зависимостей. Если один крейт зависит от tokio 1.12, а другой зависит от 1.14, Cargo.lock будет содержать только одну запись tokio 1.x, совместимую с обоими. Два ящика могут иметь совершенно разные версии зависимостей и, таким образом, иметь две записи для tokio в Cargo.lock, но только если они частично несовместимы (0.1 против 1.x против 2.x).

В-третьих, нет возможности зависеть от зависимостей другого ящика. Они не считаются частью общедоступного интерфейса ящика для определения критических изменений (если, конечно, они не выставлены на всеобщее обозрение). Крейт должен быть свободен для обновления только внутренних зависимостей, не беспокоясь о поломке других.


При этом существует механизм, который позволит это сделать: зависимости рабочего пространства. В рабочей области вы можете разрешить ящикам обращаться к одному источнику достоверности для своих зависимостей, поместив их в корневую рабочую область Cargo.toml:

# workspace/Cargo.toml
[workspace.dependencies]
tokio = { version = "1.14.1" }
# workspace/other_crate/Cargo.toml and
# workspace/my_crate/Cargo.toml
[dependencies]
tokio = { workspace = true }

Другие вопросы по теме