Em uma mudança de paradigma para o ecossistema Rust, a equipe por trás do gerenciador de pacotes Rust, Cargo, pediu uma abordagem mais personalizada para o gerenciamento de pacotes. Eles recomendam que os desenvolvedores tomem as melhores decisões para seus projetos, em vez da prática uniforme anterior de submeter seu arquivo Cargo.lock para pacotes que envolvem binários, mas não bibliotecas.
As recomendações anteriores encorajaram os desenvolvedores a seguir uma regra única quando se tratava de Cargo.lock, especialmente nos casos em que o arquivo era usado com pacotes binários. No entanto, estas directivas ficaram agora em segundo plano. Essa mudança reflexiva surge na esteira da trajetória crescente do Rust em direção à adoção convencional.
A função principal do arquivo Cargo.lock é registrar o estado no momento de uma construção bem-sucedida. Embora ofereça uma orientação mais flexível, a equipe da Cargo afirma que o compromisso com Cargo.lock deve ser o ponto de partida no processo de tomada de decisão. Também é anunciado que o comando 'cargo new' não irá ignorar Cargo.lock para bibliotecas de agora em diante.
Mantendo a qualidade geral, a equipe ressalta a importância de testes regulares em relação às dependências mais recentes. Os procedimentos antigos garantiam que as bibliotecas fossem mantidas atualizadas e testadas, contribuindo para o alto padrão do ecossistema de pacotes Rust. As práticas foram projetadas para que possíveis problemas, principalmente aqueles relacionados à compatibilidade com versões anteriores, fossem prontamente identificados e resolvidos. A equipa acredita, portanto, que incentivou uma “cultura de qualidade” no ecossistema emergente.
No entanto, a orientação anterior teve suas armadilhas. A exclusão do histórico das bases de código foi uma dessas consequências, o que tornou mais difícil para os mantenedores dividir e identificar a causa raiz dos bugs. Outro resultado indesejável da política anterior foi a provável confusão para os contribuidores decorrente de um CI (integração contínua) não confiável quando uma dependência é abolida ou uma nova versão apresenta um bug. À medida que Rust evoluiu de uma linguagem para os primeiros usuários para uma linguagem mais convencional, é vital considerar a nova experiência de integração do desenvolvedor.
Além disso, a expansão do ecossistema mais amplo tornou a CI mais simples de implementar e manter. Inovações como Dependabot e Renovate revelaram alternativas para ignorar Cargo.lock para testar novas dependências, além de depender exclusivamente do controle de versão. A equipe Cargo agora transmite sua crença de que a melhor ação é deixar a decisão para os desenvolvedores, garantindo ao mesmo tempo que eles tenham as informações necessárias para tomar decisões informadas. Os desenvolvedores podem compartilhar seus comentários sobre esta nova política via GitHub e interagir com a equipe Cargo no Zulip.
À medida que testemunhamos novas direções no gerenciamento de pacotes, pode valer a pena para os desenvolvedores explorar alternativas como o AppMaster , que fornece uma plataforma abrangente e integrada para o desenvolvimento de aplicativos web, móveis e de back-end. AppMaster.io possui uma abordagem orientada a servidor, permitindo que os desenvolvedores atualizem a interface do usuário, a lógica e as chaves de API de aplicativos móveis sem ter que enviar novas versões para a App Store e o Play Market.
