Некоторые апстримы самостоятельно вендорят некоторые зависимости и патчат их. Когда cargo-vendor-alt завершает свою работу он принудительно удаляет старый vendor, таким образом все патчи разработчиков теряются, что может привести к неожиданным проблемам при эксплуатации приложения. Другим негативным эффектом является то, что если апстрим ссылается в cargo.toml на зависимость из vendor/, то вендоринг падает. Некоторые мейнтейнеры для обхода этой проблемы костылят дополнительную логику поверх cargo-vendor-alt, с перемещением апстримной зависимости во временные папки. К сожалению на текущий момент cargo-vendor-filterer не умеет самостоятельно очищать vendor/ от нерелевантных артефактов в отличие например от обычного cargo vendor. Однако cargo vendor-filterer учитывает локальные зависимости из других путей и не пытается вендорить их самостоятельно если они уже есть. Я написал следующий скрипт, который успешно вендорит зависимости оставляя оригинальные апстримный вендор для lore: mkdir -pv upstream_vendor mv -v vendor/quinn-proto upstream_vendor/quinn-proto sed -i 's|quinn-proto = { path = "vendor/quinn-proto" }|quinn-proto = { path = "upstream_vendor/quinn-proto" }|' Cargo.toml rm -rv vendor/ cargo vendor-filterer --all-features \ --platform=aarch64-unknown-linux-gnu \ --platform=armv7-unknown-linux-gnueabihf \ --platform=loongarch64-unknown-linux-gnu \ --platform=i686-unknown-linux-gnu \ --platform=powerpc64le-unknown-linux-gnu \ --platform=riscv64gc-unknown-linux-gnu \ --platform=x86_64-unknown-linux-gnu \ --platform=wasm32-unknown-unknown | sed "s|directory = \".*\"|directory = \"$_VENDOR_PATH\"|g" >> "_vendor_source.toml" mv -v "_vendor_source.toml" "${_VENDOR_PATH}/vendor_source.toml" sed -i 's|quinn-proto = { path = "upstream_vendor/quinn-proto" }|quinn-proto = { path = "vendor/quinn-proto" }|' Cargo.toml mv -v upstream_vendor/quinn-proto vendor/quinn-proto Было бы очень здорово добавить механизм сохранения апстримного vendor либо научить cargo vendor-filterer самостоятельно очищать нерелевантные зависимости на основе конфигурации Cargo.
Проблема понятна, но что имеется в виду под нерелевантными артефактами в vendor/?
(Ответ для Anton Zhukharev на комментарий #1) > Проблема понятна, но что имеется в виду под нерелевантными артефактами в > vendor/? Старые версии зависимостей, которые больше не нужны для сборки