W ramach zmiany paradygmatu ekosystemu Rust zespół odpowiedzialny za menedżera pakietów Rust, Cargo, wezwał do bardziej spersonalizowanego podejścia do zarządzania pakietami. Zalecają, aby programiści podejmowali najlepsze decyzje dla swoich projektów, zamiast dotychczasowej jednolitej praktyki polegającej na udostępnianiu pliku Cargo.lock dla pakietów zawierających pliki binarne, ale nie biblioteki.
Poprzednie zalecenia zachęcały programistów do trzymania się jednej uniwersalnej zasady w przypadku Cargo.lock, szczególnie w przypadkach, gdy plik był używany z pakietami binarnymi. Jednakże dyrektywy te zeszły na dalszy plan. Ta refleksyjna zmiana następuje w następstwie rosnącej trajektorii Rusta w kierunku przyjęcia go przez główny nurt.
Kluczową rolą pliku Cargo.lock jest rejestrowanie stanu w momencie pomyślnej kompilacji. Oferując bardziej elastyczne wytyczne, zespół Cargo utrzymuje, że zatwierdzenie Cargo.lock powinno być punktem wyjścia w procesie decyzyjnym. Ogłoszono również, że polecenie „cargo new” nie będzie odtąd omijać Cargo.lock dla bibliotek.
Utrzymując ogólną jakość, zespół podkreśla znaczenie regularnych testów pod kątem najnowszych zależności. Stare procedury zapewniały aktualizację i testowanie bibliotek, przyczyniając się do wysokiego standardu ekosystemu pakietów Rust. Praktyki zostały zaprojektowane w taki sposób, aby potencjalne problemy, przede wszystkim dotyczące kompatybilności wstecznej, były szybko identyfikowane i rozwiązywane. Zespół uważa zatem, że przyczyniło się to do powstania „kultury jakości” w powstającym ekosystemie.
Jednakże wcześniejsze wytyczne miały swoje pułapki. Jednym z takich następstw było usunięcie historii z baz kodu, co utrudniło opiekunom rozdzielenie i zidentyfikowanie pierwotnej przyczyny błędów. Innym niepożądanym skutkiem poprzedniej polityki było prawdopodobne zamieszanie wśród autorów wynikające z niewiarygodnego CI (ciągła integracja), gdy zależność została zniesiona lub nowa wersja zawierała błąd. Ponieważ Rust ewoluował z języka dla pierwszych użytkowników w język bardziej mainstreamowy, należy wziąć pod uwagę nowe doświadczenie w zakresie wdrażania programistów.
Co więcej, rozwój szerszego ekosystemu ułatwił wdrożenie i utrzymanie CI. Innowacje takie jak Depabot i Renovate ujawniły alternatywy dla ignorowania Cargo.lock przy testowaniu nowych zależności, inne niż poleganie wyłącznie na kontroli wersji. Zespół Cargo wyraża obecnie swoje przekonanie, że najlepszym rozwiązaniem jest pozostawienie decyzji programistom, zapewniając jednocześnie, że posiadają oni informacje niezbędne do podejmowania świadomych decyzji. Programiści mogą dzielić się swoimi opiniami na temat tej nowej polityki za pośrednictwem GitHuba i kontaktować się z zespołem Cargo w Zulip.
Ponieważ jesteśmy świadkami nowych kierunków w zarządzaniu pakietami, programiści mogą rozważyć alternatywne rozwiązania, takie jak AppMaster , które zapewniają kompleksową i zintegrowaną platformę do tworzenia aplikacji internetowych, mobilnych i backendowych. AppMaster.io oferuje podejście oparte na serwerze, umożliwiające programistom aktualizację interfejsu użytkownika, logiki i kluczy API aplikacji mobilnych bez konieczności przesyłania nowych wersji do App Store i Play Market.
