Консолидация грузовых зависимостей

У меня есть проект, у которого есть зависимость (утилита cookie), которая имеет зависимость от iron >= 0.3, <= 0.4.

Мой проект зависит от железа 0.3 (поэтому я могу использовать промежуточное ПО router, которое еще не обновлено до последнего железа).

Когда я пытаюсь скомпилировать свой проект, утилита cookie вытаскивает версию железа 0.4, и я получаю ошибки, так как используются разные версии железа.

Однако я могу сделать:

cargo update -p <cookie utility>

который (обычно) изменяет зависимость пакета от железа в соответствии с той, которую я использую, и удаляет постороннюю зависимость от железа 0.4. (Необычно, мне иногда приходится запускать эту команду пару раз, прежде чем она обновится.)

По-видимому, я не могу указать зависимую версию зависимости: Установить конкретную версию зависимости зависимости проекта от Cargo.toml или Cargo.lock.

Было бы неплохо, если бы груз мог догадаться, что я хочу использовать одну версию железа, но я понимаю, почему это невозможно. Однако я смущен тем, почему cargo update -p <package> действительно работает; кажется неинтуитивным, что он обновит зависимость для пакета.


Я предполагаю, что мой первый реальный вопрос: как я могу указать зависимости зависимостей зависимостей (когда и только тогда, когда версия, которую я хочу, находится в пределах поддерживаемой версии этой библиотеки)? Я не думаю, что решения, предложенные в связанном выше вопросе, идеальны. Я чувствую, что было бы лучше, если бы Cargo мог поддерживать это хорошо, чтобы библиотеки могли оставить свои диапазоны версий зависимостей такими же открытыми, как позволяет их функциональность.

В то же время я нашел этот "трюк", который, кажется, делает то, что я хочу (cargo update -p <pkg>). Я не выглядел супер тяжело, но это поведение, похоже, не описано ни в одном очевидном месте. Мой второй вопрос: действительно ли это способ объединения зависимостей? Есть ли место, где я могу найти дополнительную информацию об этом?


И шаги для воспроизведения:

  • Создайте новый проект: cargo new --bin ironapp; cd ironapp.
  • Создайте зависимость файлов cookie: cargo new cookie_util.
  • В cookie_util/Cargo.toml добавьте одну зависимость: iron = ">= 0.3, <= 0.4".
  • В Cargo.toml добавьте две зависимости: iron = "0.3.0" и cookie_util = { path = "cookie_util"}.
  • cargo build. Убедитесь, что в версии Cargo.lock требуются две версии железа.
  • Запустите cargo update -p cookie_util где-нибудь между 1 и 4 (или более) раза. В конце концов он удалит зависимость от iron 0.4.0.

Я только что проверил это на rustc-1.10.0/cargo-0.11.0. Я убедился, что target и Cargo.lock оба отсутствовали в начале шага 1.

4b9b3361

Прочитав комментарии cargo/issues/2064, я понял, что более надежным способом разрешения этих типов зависимостей является использование --precise. Для моего примера

cargo update -p iron:0.4.0 --precise 0.3.0

удаляет ненужную зависимость. Это требует, чтобы один копался в Cargo.lock и вручную определял, где зависимости могут сходиться, но намного лучше, чем запуск cargo update -p <pkg> и надеется на лучшее или вручную отредактировать Cargo.lock.

5
27 июля '16 в 17:08
источник