Rust 화물 팀의 새로운 지침은 패키지 관리에 대한 보다 유연한 접근 방식을 요구합니다.

Rust 생태계의 패러다임 전환에서 Rust의 패키지 관리자인 Cargo 팀은 패키지 관리에 대한 보다 개인화된 접근 방식을 요구했습니다. 그들은 라이브러리가 아닌 바이너리가 포함된 패키지에 대해 Cargo.lock 파일을 커밋하는 이전의 획일적인 관행보다는 개발자가 자신의 프로젝트에 대해 최선의 결정을 내릴 것을 권장합니다.

이전 권장 사항은 개발자가 Cargo.lock 과 관련하여 모든 경우에 적용되는 단일 규칙을 고수하도록 권장했습니다. 특히 파일이 바이너리 패키지와 함께 사용되는 경우에는 더욱 그렇습니다. 그러나 이러한 지침은 이제 뒷전으로 밀려났습니다. 이러한 반성적 변화는 Rust가 주류 채택을 향한 급성장하는 궤도에 따라 발생합니다.

Cargo.lock 파일의 핵심 역할은 성공적인 빌드 당시의 상태를 기록하는 것입니다. 보다 유연한 지침을 제공하는 동시에 Cargo 팀은 Cargo.lock 커밋이 의사 결정 프로세스의 출발점이 되어야 한다고 주장합니다. 또한 'cargo new' 명령은 앞으로 라이브러리에 대해 Cargo.lock을 우회하지 않을 것이라고 발표되었습니다.

전반적인 품질을 유지하면서 팀은 최신 종속성에 대한 정기적인 테스트의 중요성을 강조합니다. 이전 절차를 통해 라이브러리가 계속 업데이트되고 테스트되어 Rust 패키지 생태계의 높은 표준에 기여했습니다. 이러한 관행은 주로 이전 버전과의 호환성과 관련된 잠재적인 문제를 즉시 식별하고 해결하도록 설계되었습니다. 따라서 팀은 이것이 신흥 생태계에서 '품질 문화'를 장려했다고 믿습니다.

그러나 이전 지침에는 함정이 있었습니다. 코드베이스에서 기록을 삭제하는 것은 그러한 여파 중 하나였으며, 이로 인해 관리자가 버그의 근본 원인을 양분하고 식별하기가 더 어려워졌습니다. 이전 정책의 또 다른 바람직하지 않은 결과는 종속성이 폐지되거나 새로운 릴리스에 버그가 있을 때 신뢰할 수 없는 CI(지속적 통합)로 인해 기여자가 혼란을 겪을 가능성이 있다는 점이었습니다. Rust가 얼리 어답터를 위한 언어에서 보다 주류 언어로 발전함에 따라 새로운 개발자 온보딩 경험을 고려해야 합니다.

또한 더 넓은 생태계의 확장으로 인해 CI의 구현 및 유지 관리가 더욱 간편해졌습니다. Expectabot 및 Renovate와 같은 혁신은 버전 제어에만 의존하는 것 외에 새로운 종속성을 테스트하기 위해 Cargo.lock 무시하는 대안을 공개했습니다. 이제 Cargo 팀은 최선의 조치는 개발자에게 결정을 맡기고 정보에 입각한 결정을 내리는 데 필요한 정보가 있는지 확인하는 것이라는 믿음을 전달합니다. 개발자는 GitHub를 통해 이 새로운 정책에 대한 피드백을 공유하고 Zulip의 Cargo 팀과 상호 작용할 수 있습니다.

패키지 관리의 새로운 방향을 목격함에 따라 개발자는 웹, 모바일 및 백엔드 애플리케이션 개발을 위한 포괄적이고 통합된 플랫폼을 제공하는 AppMaster 와 같은 대안을 탐색하는 것이 가치가 있을 수 있습니다. AppMaster.io는 서버 중심 접근 방식을 자랑하므로 개발자는 App Store 및 Play Market에 새 버전을 제출하지 않고도 모바일 애플리케이션 UI, 로직 및 API 키를 업데이트할 수 있습니다.