Я прочитал https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
Если я правильно понимаю, когда я передам Cargo.lock в репозиторий моего крейта (который является одновременно библиотекой и исполняемым файлом), а также опубликую его на crates.io, нижестоящие крейты будут игнорировать его и создавать свою собственную привязку, правильно ?
Я нашел лучшие практики в отличном проекте ripgrep, который разбивает сам себя на несколько ящиков. Для бинарного крейта в корне они отслеживают Cargo.lock, но для библиотечных крейтов, предоставляющих функциональность для приложения (например, pcre2), они этого не делают.
Да, ящики, зависящие от вашей библиотеки, будут игнорировать ваши файлы Cargo.lock. Часто задаваемые вопросы о Cargo содержат подробнее:
Почему двоичные файлы имеют
Cargo.lockв системе контроля версий, а не библиотеки?Цель
Cargo.lock— описать состояние мира во время успешной сборки. Затем он используется для обеспечения детерминированных сборок на любой машине, на которой создается пакет, гарантируя, что компилируются точно такие же зависимости.Это свойство наиболее желательно для приложений и пакетов, которые находятся в самом конце цепочки зависимостей (двоичные файлы). В результате рекомендуется, чтобы все двоичные файлы проверяли свои файлы
Cargo.lock.С библиотеками ситуация несколько иная. Библиотека используется не только разработчиками библиотеки, но и любыми последующими потребителями библиотеки. Пользователи, зависящие от библиотеки, не будут проверять
Cargo.lockбиблиотеки (даже если она существует). Именно потому, что библиотека не должна быть детерминистически перекомпилирована для всех пользователей библиотеки.Если библиотека в конечном итоге используется транзитивно несколькими зависимостями, вполне вероятно, что желательна только одна копия библиотеки (на основе совместимости semver). Если бы Cargo использовал все файлы
Cargo.lockзависимостей, то можно было бы использовать несколько копий библиотеки и, возможно, даже конфликт версий.Другими словами, библиотеки указывают несколько требований к своим зависимостям, но не могут видеть полную картину. Только конечные продукты, такие как двоичные файлы, имеют полную картину, чтобы решить, какие версии зависимостей следует использовать.
