En un cambio de paradigma para el ecosistema de Rust, el equipo detrás del administrador de paquetes de Rust, Cargo, ha pedido un enfoque más personalizado para la gestión de paquetes. Recomiendan que los desarrolladores tomen las mejores decisiones para sus proyectos, en lugar de la práctica uniforme anterior de enviar su archivo Cargo.lock para paquetes que involucran binarios pero no bibliotecas.
Las recomendaciones anteriores alentaron a los desarrolladores a seguir una regla única cuando se trataba de Cargo.lock, especialmente en los casos en que el archivo se usaba con paquetes binarios. Sin embargo, estas directivas ahora han pasado a un segundo plano. Este cambio reflexivo se produce a raíz de la floreciente trayectoria de Rust hacia la adopción generalizada.
La función clave del archivo Cargo.lock es registrar el estado en el momento de una compilación exitosa. Si bien ofrece una orientación más flexible, el equipo de Cargo sostiene que comprometerse con Cargo.lock debería ser el punto de partida en el proceso de toma de decisiones. También se anuncia que el comando 'cargo new' no omitirá Cargo.lock para las bibliotecas de ahora en adelante.
Para mantener la calidad general, el equipo subraya la importancia de realizar pruebas periódicas con las dependencias más recientes. Los procedimientos antiguos garantizaban que las bibliotecas se mantuvieran actualizadas y probadas, lo que contribuía al alto estándar del ecosistema de paquetes Rust. Las prácticas se diseñaron para que los posibles problemas, principalmente los relacionados con la compatibilidad con versiones anteriores, se identificaran y resolvieran rápidamente. Por lo tanto, el equipo cree que fomentó una "cultura de calidad" en el ecosistema emergente.
Sin embargo, la orientación anterior ha tenido sus inconvenientes. Eliminar el historial de las bases de código fue una de esas consecuencias, lo que hizo más difícil para los mantenedores dividir e identificar la causa raíz de los errores. Otro resultado indeseable de la política anterior fue la probable confusión para los contribuyentes derivada de una CI (integración continua) no confiable cuando se elimina una dependencia o una nueva versión presenta un error. A medida que Rust ha evolucionado de un lenguaje para los primeros usuarios a un lenguaje más convencional, es vital considerar la nueva experiencia de incorporación de desarrolladores.
Además, la expansión del ecosistema más amplio ha hecho que la CI sea más sencilla de implementar y mantener. Innovaciones como Dependabot y Renovate han revelado alternativas a ignorar Cargo.lock para probar nuevas dependencias, además de depender exclusivamente del control de versiones. El equipo de Cargo ahora transmite su creencia de que la mejor opción es dejar la decisión a los desarrolladores y, al mismo tiempo, garantizar que tengan la información necesaria para tomar decisiones informadas. Los desarrolladores pueden compartir sus comentarios sobre esta nueva política a través de GitHub e interactuar con el equipo de Cargo en Zulip.
A medida que somos testigos de nuevas direcciones en la gestión de paquetes, podría valer la pena que los desarrolladores exploren alternativas como AppMaster que proporciona una plataforma completa e integrada para desarrollar aplicaciones web, móviles y de backend. AppMaster.io cuenta con un enfoque basado en servidor, que permite a los desarrolladores actualizar la interfaz de usuario, la lógica y las claves API de las aplicaciones móviles sin tener que enviar nuevas versiones a App Store y Play Market.
