Los battery packs de Rust buscan simplificar la elección de crates

Elegir crates es una de las primeras fricciones que encuentran los nuevos usuarios de Rust, y una nueva idea llamada battery packs pretende reducir ese sobrecoste sin crear dependencia fija. En una entrada de blog, Niko Matsakis describe los battery packs como conjuntos seleccionados de crates organizados alrededor de un tema, con ejemplos iniciales para CLI, servicios web de backend, desarrollo embebido y manejo de errores.

El concepto es deliberadamente ligero. Un battery pack es esencialmente una lista de crates recomendados, de modo que los desarrolladores pueden sustituir cualquier opción más adelante. Matsakis dice que ya hay un prototipo funcional: instálalo con cargo install cargo-bp, y luego usa comandos como cargo bp list para explorar los packs disponibles y cargo bp add cli para añadir un conjunto de bibliotecas relacionadas con CLI. Una demostración más compleja, cargo bp add embedded, se basa en el repositorio Awesome Rust del Embedded Working Group.

Una parte clave de la propuesta es que cualquiera puede publicar un battery pack. Se distribuyen como crates llamados X-battery-pack, donde las dependencias expresan las recomendaciones del mantenedor, las features definen conjuntos comunes de crates y los ejemplos actúan como plantillas. Eso difiere de ideas previas para una biblioteca estándar ampliada de Rust al desplazar la curación a las comunidades que realmente construyen en un área determinada, desde servicios backend generales hasta objetivos embebidos altamente restringidos no-std.

Recomendado

El MX124 de McIntosh de $15,000 ofrece 13.4 canales y 7 entradas HDMI

Más allá de las dependencias

Los battery packs no se limitan a dependencias. También pueden instalar recetas y plantillas. Matsakis señala un battery pack de CI, propuesto y desarrollado por Jess Izen, que puede configurar un proyecto con flujos de trabajo de GitHub Actions preconfigurados mediante cargo bp add ci. La implementación actual usa minijinja como un sistema de plantillas ligero, aunque sugiere que esa parte podría crecer con el tiempo.

Los battery packs también pueden imponer estructura en las elecciones. En lugar de una lista plana, pueden agrupar opciones en categorías y marcarlas como 'elige como máximo una' o 'elige cualquier número'. En el ejemplo embebido, eso significa que los desarrolladores pueden seleccionar un único framework de concurrencia como embassy o rtic, mientras mezclan múltiples controladores, bibliotecas de pantalla o capas de abstracción de hardware para objetivos como esp32, nrf52840, rp2040 o stm32f0.

Financiación y coordinación del ecosistema

Matsakis sostiene que la idea podría hacer más que ayudar a los recién llegados. Dice que los grupos de trabajo en la Rust Commercial Network podrían publicar battery packs que reflejen las dependencias que realmente usan, convirtiendo esos packs en un punto de concentración para la financiación del mantenimiento. Su propuesta incluye un fondo asociado del ecosistema para battery packs patrocinados, donde empresas o individuos podrían apoyar a los mantenedores a cambio de beneficios como parches tempranos o divulgaciones de seguridad.

También plantea los battery packs como una posible forma de mejorar la interoperabilidad. Un ejemplo son los runtimes async: aunque tokio es ampliamente usado, algunas grandes compañías dependen de runtimes internos y a menudo las crates acaban definiendo sus propios traits de compatibilidad. Un battery pack neutral y patrocinado podría proporcionar un hogar para ese tipo de trabajo compartido.

Matsakis también reconoce los riesgos. Si cualquiera puede publicar un battery pack, el ecosistema podría terminar con demasiados. Él argumenta que probablemente surgirían unos pocos puntos de partida obvios, mientras que los packs de nicho podrían seguir sirviendo a comunidades especializadas. También es explícito en que los battery packs no deben congelar el ecosistema: como los proyectos dependen de las crates subyacentes, no del battery pack en sí, un pack puede evolucionar de una recomendación a otra sin romper a los usuarios existentes. Cita el análisis de CLI de Rust como ejemplo de ese tipo de evolución, pasando de docopt a clap a structopt, con structopt ahora integrado en clap.

El argumento más amplio es el mismo que Rust ha mantenido durante mucho tiempo: mantener la biblioteca estándar pequeña, apostar por el ecosistema y añadir estructura solo cuando el ecosistema crezca lo suficiente como para que el conocimiento tácito se convierta en una barrera. Matsakis dice que crates.io puede haber alcanzado ese punto.