Actualización de desarrollo de crates.io

 (blog.rust-lang.org)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • En los últimos 6 meses, crates.io incorporó un visor de código fuente para inspeccionar directamente los paquetes publicados, además de introducir un sistema de cuentas independiente de GitHub y reforzar la orientación sobre seguridad y reemplazos por la biblioteca estándar
  • La nueva pestaña Code admite búsqueda de archivos, resaltado de sintaxis y selección de líneas compartible, y usa ZIP y manifiestos JSON en el CDN junto con solicitudes HTTP de rango para cargar solo los archivos necesarios sin aumentar la carga del servidor API
  • Conforme al RFC #3946, comenzó la implementación de nombres de usuario propios de crates.io; tras completar el cambio de nombre de usuario y revisiones de seguridad, planean admitir otros proveedores de autenticación además de GitHub
  • El frontend fue migrado por completo de Ember.js a Svelte, y también se mejoraron la búsqueda, la consulta de dependencias inversas, el caché del CDN y el procesamiento del índice Git para aumentar rendimiento y estabilidad
  • Se muestran en las páginas de paquetes las advertencias de mantenimiento discontinuado de RustSec y APIs de reemplazo en la biblioteca estándar como std::sync::LazyLock, para facilitar auditorías de dependencias y eliminar dependencias innecesarias

Visor de código fuente para inspeccionar paquetes publicados

  • En la nueva pestaña Code de la página del paquete se pueden explorar dentro de crates.io los archivos de cada versión publicada
    • Muestra no el repositorio vinculado, sino los archivos que cargo realmente descarga al agregar una dependencia
    • También permite revisar archivos que no existen en el repositorio, como el Cargo.toml normalizado que genera cargo, lo que facilita auditar dependencias
  • El visor admite búsqueda en el árbol de archivos, resaltado de sintaxis y selección de líneas al estilo GitHub
    • Al hacer clic o arrastrar sobre los números de línea, se genera una URL compartible con formato #L10-L20
  • El servidor genera para todas las versiones publicadas archivos ZIP y un manifiesto JSON que describe la composición de archivos
    • Como el archivo .crate que usa cargo es un tarball gzip que no admite acceso aleatorio, se vuelve a empaquetar en segundo plano como un ZIP navegable
    • El ZIP y el manifiesto se sirven mediante un CDN estático
    • El frontend primero obtiene el manifiesto y luego carga cada archivo solo cuando hace falta mediante solicitudes HTTP de rango
    • La exploración del código prácticamente no añade carga al servidor API de crates.io, y también se procesaron en lote las versiones existentes para dar soporte incluso a lanzamientos antiguos
  • La biblioteca de renderizado del visor de código originalmente es un renderizador de diferencias, y también están desarrollando un visor de comparación entre versiones sobre la misma infraestructura
    • Cuando esté listo, será posible revisar en crates.io los cambios exactos entre dos versiones publicadas

Cuentas de crates.io independientes de GitHub

  • El equipo de crates.io aprobó en mayo el RFC #3946
  • Antes, el inicio de sesión de GitHub y la identidad en crates.io estaban fuertemente vinculados, por lo que el nombre de usuario también quedaba determinado por la cuenta de GitHub; el RFC introduce nombres de usuario propios de crates.io independientes de la cuenta enlazada
  • Este nombre de usuario propio es un requisito previo para admitir en el futuro inicios de sesión mediante proveedores de autenticación distintos de GitHub
  • La implementación ya comenzó, pero una función importante aún incompleta y visible para los usuarios es el cambio de nombre de usuario
    • Después de completar eso, planean avanzar con más RFC e implementación para el inicio de sesión con otros proveedores de autenticación
    • Como esto afecta directamente la autenticación y la seguridad de las cuentas, el despliegue será lento, en pasos pequeños y revisados con cuidado

Avisos de seguridad y orientación sobre reemplazos de la biblioteca estándar

  • La pestaña Security ya mostraba avisos de seguridad de la base de datos de RustSec, y ahora los paquetes que RustSec marque como descontinuados también mostrarán un banner de advertencia en la parte superior de la página
    • Desde el banner se puede ir al aviso correspondiente con detalles y posibles alternativas
  • Los paquetes cuya funcionalidad fue absorbida por la biblioteca estándar muestran el banner “You might not need this dependency”
    • Por ejemplo, lazy_static puede reemplazarse por std::sync::LazyLock desde Rust 1.80
    • En la lista de dependencias, los paquetes reemplazados llevan un pequeño ícono de foco con la misma indicación
  • Los datos relacionados se gestionan en el nuevo repositorio rust-lang/std-replacement-data
    • Solo se aceptan entradas de reemplazo por la biblioteca estándar
    • Todas las entradas deben citar APIs estabilizadas de std, core o alloc y la versión correspondiente de Rust
    • Antes de agregar una entrada, se notifica al mantenedor del paquete y se le da tiempo para opinar
    • Se pueden proponer nuevas entradas al repositorio, y los datos acumulados también podrán aprovecharse en otras herramientas

Migración del frontend a Svelte completada

  • El experimento de mover el frontend de crates.io de Ember.js a Svelte concluyó con éxito
    • El nuevo frontend alcanzó paridad funcional con el anterior
    • Tras las pruebas públicas de abril, pasó a ser el frontend predeterminado a inicios de mayo
    • La aplicación Ember.js fue eliminada del repositorio
  • Fue una migración uno a uno que trasladó el diseño y las funciones existentes tal cual, para que los usuarios no percibieran cambios
  • El equipo y los contribuidores ahora pueden usar un framework moderno, reducir la barrera de entrada para nuevos contribuidores y acelerar el desarrollo iterativo; el visor de código fuente es un ejemplo de ello
  • Agradecen tanto al equipo de Ember.js, que crates.io usó durante varios años, como al de Svelte por apoyar la transición

Página de error de Ferris

  • El Ferris de las páginas de error de crates.io ahora sigue con los ojos el cursor del mouse
  • También se añadió una pequeña interacción en la página de error 404

Rendimiento de búsqueda y consulta de dependencias inversas

  • La búsqueda por relevancia antes calculaba la clasificación de todos los paquetes que coincidían con el término, lo que podía tardar 1 a 2 segundos con términos cortos o comunes
    • Ahora el cálculo se limita a los 1,000 paquetes coincidentes con más descargas recientes
  • El endpoint de dependencias inversas ya no vuelve a calcular en cada solicitud el conjunto completo de paquetes dependientes
    • Entrega los resultados desde una tabla precalculada sincronizada mediante disparadores de base de datos
    • Eso reemplaza joins costosos por escaneos de índice acotados y reduce mucho la posibilidad de timeouts

Documentación de arquitectura y renderizado de Markdown

  • ARCHITECTURE.md fue reorganizado por completo para centrarse en los sistemas de alto nivel de crates.io y cómo se conectan entre sí
    • Incluye el flujo de procesamiento que ocurre al ejecutar cargo publish
    • Explica por qué una descarga típica de paquete no pasa por el servidor API
    • Incluye cómo se calculan las cifras de descargas a partir de los logs de acceso del CDN
  • El README ahora renderiza listas de definiciones, una extensión de Markdown ampliamente usada
    • El renderizador Markdown comrak ya las admitía, pero esa extensión no estaba activada

Mejoras en la eficiencia del caché del CDN

  • Se añadió metadatos de etiquetas de caché a los archivos subidos al CDN estático
    • En lugar de enviar solicitudes de invalidación individuales por cada URL de archivo, ahora se pueden invalidar de una sola vez todos los archivos en caché de un paquete o lanzamiento específico
  • Se eliminó el encabezado de respuesta global Vary: Cookie, que interfería con el caché en CDN de respuestas de la API pública y activos del frontend
    • En su lugar, las respuestas por usuario aplican Cache-Control: no-store
    • Como resultado, mejoró la tasa de aciertos de caché en los edges del CDN

Accesibilidad y procesamiento del índice Git

  • Se mejoró la accesibilidad de crates.io para usuarios de lectores de pantalla
    • Se ocultaron los íconos decorativos del árbol de accesibilidad
    • Se corrigió la jerarquía de encabezados
    • Se aplicó marcado de lista correcto a las listas
    • Se introdujeron pruebas de snapshots ARIA para evitar que regresiones pasen sin detectarse
    • Planean seguir mejorando la accesibilidad en los próximos meses
  • La copia local del índice Git en el worker en segundo plano pasó a ser un repositorio bare y shallow
    • Eso elimina del disco alrededor de 250,000 archivos checkout y todo el historial completo de commits
    • Mejora el rendimiento de procesamiento en un contexto donde aumenta la frecuencia de publicación de paquetes
  • El squash periódico del índice ahora usa la API de GitHub en vez de generar localmente grandes paquetes Git
    • El método anterior de generar packs localmente había provocado falta de memoria en workers de producción

Canales de retroalimentación

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Lobste.rs

  • Da gusto ver que está avanzando el trabajo para separar las cuentas de crates.io de GitHub

    • Antes me gustaba la función de iniciar sesión con la cuenta de GitHub en varios servicios, pero ahora me parece menos atractiva. Tailscale soporta un proveedor de identidad OIDC, así que lo configuré para iniciar sesión usando Codeberg y WebFinger de mi dominio
      Para iniciar sesión con un correo de mi propio dominio, example@example.com, pongo un archivo JSON en https://example.com/.well-known/webfinger cuyo subject es acct:example@example.com y cuyo href del emisor de OpenID Connect es https://codeberg.org
      En la configuración de Codeberg, basta con crear una aplicación OAuth2 cuya URI de redirección sea https://login.tailscale.com/a/oauth_response, y luego ingresar en Tailscale el Client ID y el Client Secret emitidos. Parece que crates.io también ofrecerá algo parecido en el futuro

  • No me había dado cuenta de que el alcance de las mejoras en crates.io había sido tan grande. Normalmente primero buscaba en lib.rs, pero quizá pronto cambie ese hábito, y el cambio que más me gusta es Ferris

    • Me pregunto cuánto de estas mejoras se debe a la adopción de agentes

  • El cambio en los ojos de Ferris no tiene mucho sentido físicamente. La parte blanca en los ojos negros es un brillo especular, así que si el cursor del mouse fuera la fuente de luz, tampoco se puede decir bien que los ojos estén siguiendo al cursor

  • Cuando audito dependencias, primero hago un enlace simbólico de ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ a ~/cargosrc para poder acceder fácilmente a los archivos que descargó Cargo
    Para cada dependencia que voy a auditar, clono el repositorio Git, hago checkout de la versión objetivo, borro localmente los archivos rastreados y le envío SIGSTOP al proceso de rust-analyzer. Agrego la dependencia al Cargo.toml del proyecto y ejecuto cargo fetch; luego copio el contenido del directorio descargado $dependency-$version al repositorio clonado, hago commit y reviso las diferencias con un visor del historial de Git
    Al terminar la revisión, guardo con un script la combinación de dependencia, versión y hash de Cargo.lock en una base de datos de confianza para no volver a revisar la misma versión. Aunque el procedimiento parece complejo, lo tengo mayormente automatizado, así que me resulta más eficiente que la UI web, y estaría bien que Cargo soportara este tipo de proceso de revisión desde la línea de comandos. También me pregunto si existe algún plugin que ayude con la revisión en sí, más que herramientas como cargo-crev

  • La implementación donde el frontend solo obtiene el manifiesto y luego carga cada archivo según se necesita mediante solicitudes de rango HTTP está aquí, y usa DecompressionStream integrado en el navegador