Ein Repository ist mehr als seine GitHub-Präsenz: Die meiste wiederverwendbare Software wird über eine Paket-Registry ausgeliefert, und die Registry hält Verbreitungs- und Pflege-Evidenz, die GitHub nicht zeigen kann — reales Download-Volumen, Aktualität der Veröffentlichungen, Deprecation-Status. inspect.software ermittelt die Pakete, die ein Repository veröffentlicht, und führt die Registry-Daten in zwei Metriken zusammen: Ökosystem-Verbreitung und Paketpflege.
Heute gelesene Registries
| Ökosystem | Registry | Verbreitungszahl |
|---|---|---|
| JavaScript / Node | npm | monatliche Downloads |
| Python | PyPI | monatliche Downloads |
| PHP | Packagist | monatliche Downloads |
| Rust | crates.io | monatliche Downloads |
| Ruby | RubyGems | Gesamtzahl aller Downloads |
| Elixir / Erlang | Hex | Download-Zahlen |
| .NET | NuGet | Gesamtzahl aller Downloads |
| Go | Go-Modul-Proxy | kein öffentlicher Download-Zähler |
| Java / JVM | Maven Central | kein öffentlicher Paket-Download-Zähler |
Alle neun Registries steuern Fakten zu veröffentlichten Paketen — neueste Version, Aktualität der Veröffentlichungen, Versionshistorie, Deprecation-Status — zur Paketpflege bei. Wo eine Registry keine monatliche Download-Zahl veröffentlicht (RubyGems, NuGet), greift die Verbreitungsmetrik auf die Gesamtzahl aller Downloads zurück — jeweils die Zahl, die die Registry tatsächlich bereitstellt, sodass kein Ökosystem strukturell benachteiligt ist. Der Go-Modul-Proxy und Maven Central veröffentlichen keinerlei Download-Statistiken. Für Go bleibt damit die Pflege-Evidenz das einzige Signal; für Maven Central liefert die von deps.dev veröffentlichte Zahl abhängiger Projekte ein vergleichbares Verbreitungsmaß.
NuGet wird inkrementell über seinen offiziellen Katalog-Feed entdeckt. Seine öffentlichen Suchmetadaten liefern die Gesamtzahl aller Downloads, die für den Katalog-Schwellwert verwendet wird. Maven Central wird inkrementell über den offiziellen Maven Central Indexer entdeckt. Central veröffentlicht keinen Paket-Download-Zähler; die Aufnahme stützt sich stattdessen auf die deps.dev-Zahl abhängiger Projekte zusammen mit einer deklarierten GitHub-Quelle; Pakete, die den Abhängigen-Schwellwert erreichen, werden wie in anderen Ökosystemen automatisch eingereiht.
Go-Modul-Entdeckung
Der Katalog-Worker liest außerdem den offiziellen öffentlichen Go Module Index, um neue stabile Releases zu finden. Der Index veröffentlicht Modulpfad, Version und Zeitstempel, aber keinen Download-/Verbreitungszähler. Automatische Go-Kandidaten benötigen daher einen direkten github.com/owner/repo-Modulpfad und ein stabiles Release aus den letzten 730 Tagen; sie werden nach der Frische des Releases gereiht, nicht nach erfundenen Download-Zahlen. Die normale Katalog-Warteschlange mit niedriger Priorität und der Scan verifizieren das Repository weiterhin, bevor es im öffentlichen Register erscheint.
Deklarierte Abhängigkeiten
Unabhängig vom Veröffentlichen parst die Prüfung Abhängigkeitsmanifeste über die Ökosysteme hinweg — npm, PyPI, Packagist, crates.io, Go, Maven, RubyGems, NuGet und Hex — und verzeichnet die deklarierte Liste direkter Abhängigkeiten in jedem Bericht. Der Abgleich dieser Abhängigkeiten mit Registries und Schwachstellendatenbanken (Aktualität, bekannte CVEs) steht auf der veröffentlichten Methodik-Roadmap.
Alle Abhängigkeiten
Neben der direkten Liste verzeichnet die Prüfung den vollständig aufgelösten Abhängigkeitsbestand des Repositorys — direkt plus indirekt (transitiv) — aus GitHubs Abhängigkeitsgraphen, der die transitive Hülle abdeckt, wann immer das Repository eine Lockdatei eincheckt. Der Bericht weist direkte und indirekte Zahlen getrennt aus und benennt die Quelle des aufgelösten Bestands. Diese Erhebung erfolgt nach bestem Bemühen: Ist der Abhängigkeitsgraph nicht verfügbar, sagt der Bericht das ausdrücklich, und jeder andere Teil der Prüfung läuft unbeeinträchtigt weiter.
Repositories, die kein Paket veröffentlichen
Anwendungen, Infrastruktur-Repositories und Dokumentationsprojekte veröffentlichen oft nichts in einer Registry. Für sie sind die beiden registrygestützten Metriken null: aus ihren Kategorien ausgeschlossen und die Gewichte renormalisiert, niemals als null gewertet. Ein nicht veröffentlichendes Repository wird rein an seiner übrigen Evidenz gemessen — siehe der Gesundheitsindex zu den Regeln für fehlende Daten.
Zuordnung von Paket zu Repository
Ein Paket fließt nur dann in den Bericht eines Repositorys ein, wenn der Registry-Eintrag nachprüfbar auf dieses Repository zurückverweist. Ein Paket, das ein anderes Quell-Repository angibt, wird im Bericht aufgeführt, aber markiert und aus der Berechnung herausgehalten — so können Verbreitungszahlen weder geborgt noch vorgetäuscht werden.
Repositories mit mehreren Ökosystemen und Sprachen
Eine Codebasis kann legitim in mehreren Ökosystemen zugleich leben — ein Rust-Kern mit Python-Bindings und einem npm-Wrapper veröffentlicht aus einem einzigen Repository auf crates.io, PyPI und npm. Die Bewertung behandelt das bereits sauber: Download-Zahlen werden über alle verifizierten Pakete summiert. Wo immer das öffentliche Register die Ökosysteme eines Repositorys auflistet — Katalogkarten, Filter, Berichts-Chips — folgt die Reihenfolge der Stärke der Evidenz, nicht dem Alphabet: Ökosysteme mit verifizierten veröffentlichten Paketen zuerst, gereiht nach Download-Volumen; Ökosysteme, die nur in Abhängigkeitsmanifesten vorkommen, folgen. Ein Paket, das auf ein anderes Quell-Repository verweist, führt die Liste nie an.
Sprachen folgen derselben Disziplin. Für ein Repository werden die Sprachen gezeigt, die mindestens 10% seines Codes nach Volumen halten, die größte zuerst — so geben sich CI-Skripte und generiertes Markup nicht als Projektsprache aus, und eine wirklich zweisprachige Codebasis wird als solche dargestellt. Katalogkarten zeigen bis zu drei Ökosysteme und drei Sprachen je Repository.
Verwandt: Ökosystem-Verbreitung · Paketpflege · Methodikversionen