Ecosistemas de paquetes compatibles

Un repositorio es más que su presencia en GitHub: la mayor parte del software reutilizable se distribuye a través de un registro de paquetes, y el registro contiene evidencia de adopción y mantenimiento que GitHub no puede mostrar — volumen real de descargas, recencia de publicación, estado de deprecación. inspect.software resuelve los paquetes que un repositorio publica e incorpora los datos del registro en dos métricas: adopción en el ecosistema y mantenimiento de paquetes.

Registros que se leen hoy

Los nueve registros aportan hechos de paquetes publicados — última versión, recencia de publicación, historial de versiones, estado de deprecación — al mantenimiento de paquetes. Cuando un registro no publica una cifra mensual de descargas (RubyGems, NuGet), la métrica de adopción recurre a las descargas totales acumuladas — la cifra que el registro realmente proporciona, de modo que ningún ecosistema queda estructuralmente en desventaja. El proxy de módulos de Go y Maven Central no publican estadísticas de descargas de ningún tipo. Para Go, esto deja la evidencia de mantenimiento como única señal; para Maven Central, el recuento de proyectos dependientes publicado por deps.dev proporciona una medida de adopción comparable.

NuGet se descubre de forma incremental a partir de su feed de catálogo oficial. Sus metadatos públicos de búsqueda proporcionan las descargas totales acumuladas, que se usan para el umbral del catálogo. Maven Central se descubre de forma incremental a partir del Maven Central Indexer oficial. Central no publica ningún contador de descargas de paquetes, por lo que la elegibilidad se apoya en cambio en el recuento de proyectos dependientes de deps.dev junto con una fuente de GitHub declarada; los paquetes que alcanzan el umbral de dependientes se encolan automáticamente como en los demás ecosistemas.

Descubrimiento de módulos de Go

El worker del catálogo también lee el Go Module Index público oficial para encontrar nuevas versiones estables. El índice publica una ruta de módulo, una versión y una marca de tiempo, pero ningún contador de descargas/adopción. Los candidatos automáticos de Go necesitan por tanto una ruta de módulo directa github.com/owner/repo y una versión estable publicada en los últimos 730 días; se clasifican por frescura de la versión, no por cifras de descargas inventadas. La cola de catálogo de baja prioridad habitual y la inspección siguen verificando el repositorio antes de que aparezca en el registro público.

Dependencias declaradas

Con independencia de la publicación, la inspección analiza los manifiestos de dependencias de los distintos ecosistemas — npm, PyPI, Packagist, crates.io, Go, Maven, RubyGems, NuGet y Hex — y registra en cada informe la lista de dependencias directas declaradas. Resolver esas dependencias contra los registros y las bases de datos de vulnerabilidades (frescura, CVE conocidos) figura en la hoja de ruta publicada de la metodología.

Todas las dependencias

Junto a la lista directa, la inspección registra el conjunto completo de dependencias resueltas del repositorio — directas más indirectas (transitivas) — a partir del grafo de dependencias de GitHub, que cubre el cierre transitivo siempre que el repositorio confirme un lockfile. El informe indica los recuentos directo e indirecto por separado y nombra la fuente del conjunto resuelto. Esta recopilación se realiza en la medida de lo posible: cuando el grafo de dependencias no está disponible, el informe lo indica explícitamente y el resto de la inspección continúa sin verse afectado.

Repositorios que no publican ningún paquete

Las aplicaciones, los repositorios de infraestructura y los proyectos de documentación a menudo no publican nada en ningún registro. Para ellos, las dos métricas basadas en registros son null: excluidas de sus categorías con renormalización de pesos, nunca contadas como cero. Un repositorio que no publica se mide exclusivamente por su otra evidencia — véanse las reglas de datos ausentes en el índice de salud.

Correspondencia entre paquete y repositorio

Un paquete solo contribuye al informe de un repositorio cuando la entrada del registro apunta de forma verificable a ese repositorio. Un paquete que declara un repositorio de origen distinto se lista en el informe pero se marca y se deja fuera del cálculo — lo que evita que las cifras de adopción se tomen prestadas o se falsifiquen.

Repositorios multiecosistema y multilenguaje

Una misma base de código puede vivir legítimamente en varios ecosistemas a la vez — un núcleo en Rust con bindings de Python y un wrapper de npm publica en crates.io, PyPI y npm desde un único repositorio. La puntuación ya trata esto de forma sólida: los recuentos de descargas se suman entre todos los paquetes verificados. Allí donde el registro público lista los ecosistemas de un repositorio — tarjetas del catálogo, filtros, distintivos del informe — el orden refleja la fuerza de la evidencia, no el alfabeto: los ecosistemas con paquetes publicados verificados van primero, ordenados por volumen de descargas; los ecosistemas vistos solo en manifiestos de dependencias van después. Un paquete que apunta a un repositorio de origen distinto nunca encabeza la lista.

Los lenguajes siguen la misma disciplina. Los lenguajes mostrados para un repositorio son los que concentran al menos el 10% de su código por volumen, de mayor a menor — de modo que los scripts de CI y el marcado generado no se hacen pasar por un lenguaje del proyecto, y una base de código genuinamente bilingüe se presenta como tal. Las tarjetas del catálogo muestran hasta tres ecosistemas y tres lenguajes por repositorio.

Relacionado: adopción en el ecosistema · mantenimiento de paquetes · versiones de la metodología