Репозиторій — це більше, ніж його присутність на GitHub: більшість повторно використовуваного програмного забезпечення постачається через реєстр пакетів, і саме реєстр зберігає докази впровадження та супроводу, яких GitHub показати не може, — реальні обсяги завантажень, свіжість публікацій, стан застарілості. inspect.software визначає пакети, які публікує репозиторій, і вплітає дані реєстрів у дві метрики: впровадження в екосистемі та супровід пакетів.
Реєстри, які читаються сьогодні
| Екосистема | Реєстр | Показник впровадження |
|---|---|---|
| JavaScript / Node | npm | завантаження за місяць |
| Python | PyPI | завантаження за місяць |
| PHP | Packagist | завантаження за місяць |
| Rust | crates.io | завантаження за місяць |
| Ruby | RubyGems | сумарні завантаження за весь час |
| Elixir / Erlang | Hex | дані про завантаження |
| .NET | NuGet | сумарні завантаження за весь час |
| Go | проксі модулів Go | немає публічного лічильника завантажень |
| Java / JVM | Maven Central | немає публічного лічильника завантажень пакетів |
Усі дев'ять реєстрів постачають факти про опубліковані пакети — останню версію, свіжість публікації, історію версій, стан застарілості — до супроводу пакетів. Там, де реєстр не публікує місячних цифр завантажень (RubyGems, NuGet), метрика впровадження переходить на сумарні завантаження за весь час — той показник, який реєстр справді надає, тож жодна екосистема не опиняється у структурно гіршому становищі. Проксі модулів Go та Maven Central не публікують жодної статистики завантажень. Для Go це залишає докази супроводу єдиним сигналом; для Maven Central порівнянну міру впровадження дає кількість залежних проєктів, яку публікує deps.dev.
NuGet поступово відкривається через його офіційний каталоговий фід. Публічні метадані пошуку надають сумарні завантаження за весь час, які використовуються для порога включення в каталог. Maven Central поступово відкривається через офіційний Maven Central Indexer. Central не публікує лічильника завантажень пакетів, тож придатність натомість спирається на кількість залежних проєктів за deps.dev разом із задекларованим джерелом на GitHub; пакети, що досягають порога залежних проєктів, автоматично стають у чергу, як і в інших екосистемах.
Виявлення модулів Go
Воркер каталогу також читає офіційний публічний Go Module Index, щоб знаходити нові стабільні релізи. Індекс публікує шлях модуля, версію та позначку часу, але жодного лічильника завантажень чи впровадження. Тому автоматичні кандидати Go потребують прямого шляху модуля github.com/owner/repo та стабільного релізу, опублікованого впродовж останніх 730 днів; вони ранжуються за свіжістю релізу, а не за вигаданими цифрами завантажень. Звичайна низькопріоритетна черга каталогу та сканування все одно верифікують репозиторій, перш ніж він з'явиться в публічному реєстрі.
Задекларовані залежності
Незалежно від публікації, інспекція розбирає маніфести залежностей в усіх екосистемах — npm, PyPI, Packagist, crates.io, Go, Maven, RubyGems, NuGet та Hex — і фіксує задекларований список прямих залежностей у кожному звіті. Звірення цих залежностей з реєстрами та базами вразливостей (свіжість, відомі CVE) внесене до опублікованої дорожньої карти методології.
Усі залежності
Поруч із прямим списком інспекція фіксує повний розв'язаний набір залежностей репозиторію — прямі плюс непрямі (транзитивні) — з графа залежностей GitHub, який покриває транзитивне замикання щоразу, коли репозиторій коммітить lockfile. Звіт наводить кількості прямих і непрямих залежностей окремо та називає джерело розв'язаного набору. Цей збір виконується за принципом найкращих зусиль: коли граф залежностей недоступний, звіт явно про це повідомляє, а решта інспекції проходить без змін.
Репозиторії, що не публікують пакетів
Застосунки, інфраструктурні репозиторії та документаційні проєкти часто не публікують нічого в жодному реєстрі. Для них обидві метрики, що спираються на реєстри, дорівнюють null: виключаються зі своїх категорій з перенормалізацією ваг і ніколи не зараховуються як нуль. Репозиторій без публікацій вимірюється виключно за рештою своїх доказів — див. індекс здоров'я щодо правил для відсутніх даних.
Зіставлення пакета з репозиторієм
Пакет впливає на звіт репозиторію лише тоді, коли запис у реєстрі верифіковано вказує назад на цей репозиторій. Пакет, що заявляє інший репозиторій-джерело, наводиться у звіті, але позначається і не бере участі в обчисленні — це не дає позичати чи підробляти цифри впровадження.
Багатоекосистемні, багатомовні репозиторії
Одна кодова база може правомірно жити в кількох екосистемах одночасно — ядро на Rust з прив'язками для Python та обгорткою для npm публікується на crates.io, PyPI та npm з одного репозиторію. Оцінювання вже обробляє це коректно: кількості завантажень підсумовуються за всіма верифікованими пакетами. Всюди, де публічний реєстр перелічує екосистеми репозиторію — картки каталогу, фільтри, позначки у звіті, — порядок відображає силу доказів, а не алфавіт: екосистеми з верифікованими опублікованими пакетами йдуть першими, ранжовані за обсягом завантажень; екосистеми, помічені лише в маніфестах залежностей, — за ними. Пакет, що вказує на інший репозиторій-джерело, ніколи не очолює список.
Мови підпорядковуються тій самій дисципліні. Для репозиторію показуються ті мови, що складають щонайменше 10% його коду за обсягом, від найбільшої — щоб CI-скрипти та згенерована розмітка не видавали себе за мову проєкту, а справді двомовна кодова база подавалася як така. Картки каталогу показують до трьох екосистем і трьох мов на репозиторій.
Дивіться також: впровадження в екосистемі · супровід пакетів · версії методології