В рамках смены парадигмы экосистемы Rust команда менеджера пакетов Rust Cargo призвала к более персонализированному подходу к управлению пакетами. Они рекомендуют разработчикам принимать лучшие решения для своих проектов, а не использовать прежнюю единую практику фиксации файла Cargo.lock для пакетов, включающих двоичные файлы, но не библиотеки.
Предыдущие рекомендации призывали разработчиков придерживаться единого правила, когда дело касалось Cargo.lock, особенно в тех случаях, когда файл использовался с двоичными пакетами. Однако сейчас эти директивы отошли на второй план. Это рефлексивное изменение происходит вслед за растущей траекторией распространения Rust в сторону массового внедрения.
Ключевая роль файла Cargo.lock — запись состояния на момент успешной сборки. Предлагая более гибкое руководство, команда Cargo утверждает, что фиксация Cargo.lock должна стать отправной точкой в процессе принятия решений. Также объявлено, что команда «cargo new» отныне не будет обходить Cargo.lock для библиотек.
Поддерживая общее качество, команда подчеркивает важность регулярного тестирования самых последних зависимостей. Старые процедуры гарантировали постоянное обновление и тестирование библиотек, что способствовало поддержанию высоких стандартов экосистемы пакетов Rust. Эти методы были разработаны таким образом, чтобы потенциальные проблемы, в первую очередь связанные с обратной совместимостью, можно было быстро выявлять и решать. Поэтому команда считает, что это способствовало развитию «культуры качества» в развивающейся экосистеме.
Однако предыдущие рекомендации имели свои недостатки. Одним из таких последствий было удаление истории из кодовых баз, из-за которого специалистам по сопровождению стало сложнее анализировать и выявлять первопричины ошибок. Другим нежелательным результатом предыдущей политики была вероятная путаница для участников, возникающая из-за ненадежной CI (непрерывной интеграции), когда зависимость отменяется или в свежем выпуске содержится ошибка. Поскольку Rust превратился из языка для первых пользователей в более распространенный язык, жизненно важно учитывать новый опыт адаптации разработчиков.
Более того, расширение более широкой экосистемы упростило внедрение и обслуживание CI. Такие инновации, как Dependabot и Renovate, открыли альтернативы игнорированию Cargo.lock для тестирования новых зависимостей, помимо использования исключительно контроля версий. Команда Cargo теперь выражает свою уверенность в том, что лучший вариант действий — оставить решение разработчикам, гарантируя при этом, что у них есть необходимая информация для принятия обоснованных решений. Разработчики могут поделиться своими отзывами об этой новой политике через GitHub и пообщаться с командой Cargo на Zulip.
Поскольку мы являемся свидетелями новых направлений в управлении пакетами, разработчикам, возможно, стоит изучить альтернативы, такие как AppMaster , которые предоставляют комплексную и интегрированную платформу для разработки веб-, мобильных и серверных приложений. AppMaster.io может похвастаться серверным подходом, позволяющим разработчикам обновлять пользовательский интерфейс, логику и ключи API мобильных приложений без необходимости отправлять новые версии в App Store и Play Market.
