Cuando se aplica al software, el retraso del sistema se puede definir aproximadamente como el retraso general entre la implementación deseada del código y la implementación real del código. Idealmente, este retraso debería ser mínimo y los programadores podrán realizar cambios y mejoras instantáneos en sus aplicaciones.
En realidad, las cosas son más complicadas, y las cosas tienden a complicarse con el tiempo. Durante más de seis años, el equipo de Snapcraft ha estado trabajando para hacer que su producto principal sea modular, eficiente y útil para los desarrolladores de Snap, ampliando su funcionalidad e introduciendo nuevas funciones con el tiempo. En cierto modo, es un producto completo que cumple bien su propósito. Pero hay formas de mejorar las cosas. Este artículo analiza el futuro de Snapcraft.
El concepto básico gira en torno a dividir Snapcraft en componentes más pequeños, más modulares y reutilizables que se pueden usar en una variedad de productos diferentes.La base común de este trabajo es un conjunto de bibliotecas artesanales, como hemos piezas artesanales entrada en el blog. La teoría exige el uso de un generador de piezas genérico basado en proveedores artesanales y piezas artesanales, y agregar la funcionalidad Snapcraft como una capa separada. El único problema es, ¿Cuál es la velocidad aerodinámica de una golondrina? ¿Qué tan difícil es esto para la arquitectura y la implementación?
Justo antes de las vacaciones, el equipo de Snapcraft se propuso responder a esta pregunta exacta y examinar el grado de modularidad de su enfoque.
Aquí hay un resumen rápido de lo que se ha hecho:
- El código base actual de Snapcraft ahora se considera heredado. El punto de entrada principal de este paquete se ejecutará cuando se requiera una versión anterior de Snapcraft.
- Legacy Snapcraft guarda los datos de configuración de los elementos en forma de diccionario.Esto ha sido cambiado para usar nerd Modelo. Asimismo, el esquema JSON también debe mantenerse por separado.
- Se hizo un prototipo simple utilizando la base core22 (imagen de desarrollo) para generar un paquete instantáneo instalable que contiene la aplicación de prueba.
La primera prueba de concepto solo cubrió algunos aspectos de las capacidades de Snapcraft, pero ilustró una transición relativamente rápida al nuevo diseño modular. Sin embargo, todavía hay bastantes desafíos técnicos que abordar, incluida la validación de datos a nivel global, procesamiento de sintaxis, extensiones, adopción de información de piezas, adopción de información de Appstream, complementos específicos de Snapcraft reimplementados como complementos de aplicaciones para piezas artesanales o binarios Hacer reparaciones de archivos .
Luego está la implementación del manejo de argumentos en la línea de comandos usando craft-cli, la nueva interacción de la Tienda y las capacidades de compilación remota, y hacer que la experiencia del usuario en la línea de comandos sea más limpia y consistente.
Es importante tener en cuenta que este cambio (algo) fundamental no interrumpirá los patrones de uso actuales. Los proyectos con core18 y core20 seguirán utilizando Snapcraft monolítico, mientras que el nuevo Snapcraft modular se utilizará para core22 y superiores. Se colocará un mecanismo alternativo para decidir qué implementación se requiere durante el proceso de compilación. De esta manera, miles de proyectos que felizmente usan Snapcraft pueden continuar funcionando y solo verse afectados cuando se trasladan a una nueva base.
Vaya audazmente a donde nadie ha estado antes. Lo mismo ocurre con las naves espaciales y Snapcraft. En el futuro, debería ver bastantes desarrollos nuevos e interesantes en el producto, todos diseñados para hacer las cosas más simples, rápidas y sólidas sin afectar negativamente la experiencia del usuario.Si tiene algún comentario o idea, o si desea contribuir, por favor únase nuestro foro Háganos saber sus pensamientos.
