In einem Paradigmenwechsel für das Rust-Ökosystem hat das Team hinter Rusts Paketmanager Cargo einen personalisierteren Ansatz für die Paketverwaltung gefordert. Sie empfehlen Entwicklern, die besten Entscheidungen für ihre Projekte zu treffen, anstatt die bisher einheitliche Praxis, ihre Cargo.lock-Datei für Pakete zu übernehmen, die Binärdateien, aber keine Bibliotheken umfassen.
Die vorherigen Empfehlungen ermutigten Entwickler, sich bei Cargo.lock an eine einheitliche Regel zu halten, insbesondere in Fällen, in denen die Datei mit Binärpaketen verwendet wurde. Allerdings sind diese Richtlinien inzwischen in den Hintergrund gerückt. Dieser nachdenkliche Wandel erfolgt im Zuge von Rusts aufkeimendem Weg hin zur Mainstream-Akzeptanz.
Die Schlüsselrolle der Datei Cargo.lock besteht darin, den Status zum Zeitpunkt eines erfolgreichen Builds aufzuzeichnen. Das Cargo-Team bietet zwar eine flexiblere Anleitung, vertritt jedoch die Auffassung, dass die Festlegung Cargo.lock der Ausgangspunkt im Entscheidungsprozess sein sollte. Es wird außerdem angekündigt, dass der Befehl „cargo new“ Cargo.lock für Bibliotheken künftig nicht mehr umgehen wird.
Um die Gesamtqualität aufrechtzuerhalten, unterstreicht das Team die Bedeutung regelmäßiger Tests anhand der neuesten Abhängigkeiten. Die alten Verfahren stellten sicher, dass die Bibliotheken auf dem neuesten Stand gehalten und getestet wurden, was zum hohen Standard des Rust-Paket-Ökosystems beitrug. Die Vorgehensweisen wurden so konzipiert, dass potenzielle Probleme, vor allem solche im Zusammenhang mit der Abwärtskompatibilität, umgehend erkannt und gelöst werden. Das Team ist daher davon überzeugt, dass es eine „Qualitätskultur“ im entstehenden Ökosystem gefördert hat.
Die früheren Leitlinien hatten jedoch ihre Tücken. Das Löschen des Verlaufs aus den Codebasen war eine dieser Folgen, was es für Betreuer schwieriger machte, die Grundursache von Fehlern zu zerlegen und zu identifizieren. Ein weiteres unerwünschtes Ergebnis der vorherigen Richtlinie war die wahrscheinliche Verwirrung für Mitwirkende aufgrund einer nicht vertrauenswürdigen CI (kontinuierliche Integration), wenn eine Abhängigkeit abgeschafft wird oder eine neue Version einen Fehler aufweist. Da sich Rust von einer Sprache für Early Adopters zu einer Mainstream-Sprache entwickelt hat, ist die Onboarding-Erfahrung neuer Entwickler von entscheidender Bedeutung.
Darüber hinaus hat die Erweiterung des breiteren Ökosystems dazu geführt, dass CI einfacher zu implementieren und zu warten ist. Innovationen wie Dependabot und Renovate haben Alternativen zum Ignorieren Cargo.lock zum Testen neuer Abhängigkeiten aufgezeigt, anstatt sich ausschließlich auf die Versionskontrolle zu verlassen. Das Cargo-Team bringt nun seine Überzeugung zum Ausdruck, dass der beste Handlungsaufruf darin besteht, die Entscheidung den Entwicklern zu überlassen und gleichzeitig sicherzustellen, dass sie über die notwendigen Informationen verfügen, um fundierte Entscheidungen zu treffen. Entwickler können ihr Feedback zu dieser neuen Richtlinie über GitHub teilen und mit dem Cargo-Team auf Zulip interagieren.
Da wir neue Richtungen in der Paketverwaltung erleben, könnte es sich für Entwickler lohnen, Alternativen wie AppMaster zu erkunden, die eine umfassende und integrierte Plattform für die Entwicklung von Web-, Mobil- und Backend-Anwendungen bieten. AppMaster.io verfügt über einen servergesteuerten Ansatz, der es Entwicklern ermöglicht, die Benutzeroberfläche, Logik und API-Schlüssel mobiler Anwendungen zu aktualisieren, ohne neue Versionen im App Store und Play Market einreichen zu müssen.
