Konsolidacja zależności ładunkowych

Question

Mam projekt, który ma zależność (narzędzie cookie), który jest zależny od iron>= 0.3, <= 0.4.

Mój projekt jest zależny od żelaza 0.3 (dzięki czemu mogę korzystać z oprogramowania pośredniego router, które nie zostało jeszcze zaktualizowane do najnowszego żelaza).

Kiedy próbuję skompilować mój projekt, narzędzie cookie pobiera wersję żelaza z wersji 0.4 i pojawiają się błędy, ponieważ używane są różne wersje żelaza.

Mogę jednak zrobić:

cargo update -p <cookie utility> 

który (zazwyczaj) zmienia zależność tego pakietu w sprawie żelaza, aby dopasować jeden używam, i usuwa zależność od obcego żelaza 0.4. (Dziwnie, czasami muszę uruchomić to polecenie kilka razy przed aktualizacją.)

Najwyraźniej nie mogę określić zależności zależności: Set specific version of the dependency of a project's dependency in Cargo.toml or Cargo.lock.

Byłoby miło, gdyby ładunek mógł odgadnąć, że chcę użyć jednej wersji żelaza, ale rozumiem, dlaczego nie może. Jestem jednak zdezorientowany, dlaczego tak naprawdę działa cargo update -p <package>; wydaje się nieintuicyjne, że zaktualizuje zależność dla pakietu.

---

Chyba moje pierwsze pytanie brzmi: w jaki sposób mogę określić wersje zależność zależnościami (wtedy i tylko wtedy, gdy wersja Chcę mieści się w zakresie obsługiwanych wersji tej biblioteki)? Nie sądzę, że rozwiązania sugerowane w powyższym pytaniu są idealne. Wydaje mi się, że lepiej byłoby, gdyby Cargo mogła tak dobrze to wspierać, aby biblioteki mogły pozostawić zakresy zależności zależności tak otwarte, jak pozwala na to ich funkcjonalność.

W tym samym czasie znalazłem tę "sztuczkę", która wydaje się robić to, co chcę (cargo update -p <pkg>). Nie wyglądałam bardzo ciężko, ale to zachowanie nie wydaje się być opisane w żadnym oczywistym miejscu. Moje drugie pytanie brzmi: czy jest to ważny sposób na połączenie zależności? Czy jest jakieś miejsce, gdzie mogę znaleźć więcej informacji na ten temat?

---

i kroki, aby odtworzyć:

1. Utwórz nowy projekt: cargo new --bin ironapp; cd ironapp.
2. Utwórz zależność cookie: cargo new cookie_util.
3. W cookie_util/Cargo.toml dodaj jedną zależność: iron = ">= 0.3, <= 0.4".
4. W Cargo.toml dodaj dwie zależności: iron = "0.3.0" i cookie_util = { path = "cookie_util"}.
5. cargo build. Potwierdź, że dwie wersje żelaza są wymagane w Cargo.lock.
6. Uruchom cargo update -p cookie_util od 1 do 4 (lub więcej) razy. W końcu usunie zależność od iron 0.4.0.

Właśnie przetestowałem to na rustc-1.10.0/cargo-0.11.0. Upewniłem się, że target i Cargo.lock były nieobecne na początku kroku 1.

Answer 1

Czytając komentarze cargo/issues/2064, zdałem sobie sprawę, że bardziej niezawodnym sposobem rozwiązania tego typu zależności jest użycie flagi --precise. Dla mojego przykładu,

cargo update -p iron:0.4.0 --precise 0.3.0 

usuwa niepotrzebną zależność. Wymaga to, aby zagłębić się w Cargo.lock i ręcznie określić, gdzie zależności mogą się zbiec, ale jest o wiele lepszy niż uruchomienie cargo update -p <pkg> i mieć nadzieję na najlepsze lub ręcznie edytować Cargo.lock.