Don't couple your Go code to GitHub

Go позволяет использовать путь импорта как адрес для загрузки кода, что упрощает распространение библиотек без централизованного репозитория. Однако привязка импорта к конкретному хостингу вроде GitHub создаёт жёсткую зависимость: при миграции на GitLab или другой сервис приходится менять все импорты в коде, что становится непрактичным и дорогостоящим. Автор приводит пример компании, которая вынуждена была одновременно платить за три хостинга, потому что изменение путей импорта требовало слишком много усилий.

Решение — использовать собственный домен (например, go.iain.rocks) для пространства имён Go. На этом домене настраивается веб-сервер, который при запросе с параметром ?go-get=1 отдаёт HTML-файл с мета-тегами go-import и go-source, указывающими на реальный репозиторий. Для обычных посетителей настроен редирект на GitHub. Таким образом, импорт вида go.iain.rocks/boneclone остаётся неизменным независимо от того, где фактически расположен код. Автор предоставляет готовые конфиги Nginx и HTML-файл для быстрого старта и рекомендует этот подход всем командам, использующих Go в продакшене.

Комментарии (175)

Привязка импортов к GitHub — уязвимость, но кастомные домены лишь переносят риск на управление доменами, не решая фундаментальной проблемы надёжности именования в распределённых системах. jerf: любая система именования — человеческое построение, может сломаться; замена GitHub на другой домен не решает проблему, а смещает точку отказа. thih9: коммерческим командам следует использовать кастомные домены для внутренних пакетов независимо от языка, так как даже ссылки в комментариях ломаются при миграции. p4bl0: кастомный домен может быть уничтожен регистратором (как VeriSign), поэтому стратегия не менее рискованна. SenHeng: GitHub надёжнее кастомного домена, так как у открытых разработчиков выше шанс перестать платить за домен, чем GitHub исчезнет. st3fan: при выходе компании из бизнеса её домен может быть перехвачен третьей стороной, что приведёт к захвату зависимостей — уже происходило в других экосистемах. rot256: Go смешивает 'что' и 'где' — фундаментальный недостаток, усугублённый отсутствием изначальной поддержки версионирования и блокировки зависимостей. gumby: следует использовать URN вместо URL для импортов, чтобы отделить идентификатор от места хранения и поддерживать несколько резолверов с подписями. nirui: GitHub-URL — достоверный идентификатор, кастомный домен — нет; система привыкла к GitHub как к стандарту, поэтому домен лучше использовать для брендинга, а не идентификации. deanc: если автор пакета умрёт или домен истечёт — зависимости станут недоступными без восстановления. hk1337: даже при отказе от GitHub пакеты будут ссылаться на GitLab, Codeberg или локальные серверы — проблема не исчезает, только смещается. pidgeon_lover: модель динамической загрузки зависимостей вредна, как stub-установщики; через десятилетия такие импорты могут быть скомпрометированы. okanat: единственный надёжный барьер в Go — сетевой; домен с DNS — минимально необходимый уровень абстракции для безопасного разделения. shieldagent: после переименования организации replace в go.mod покрыл прямые зависимости, но транзитивные импорты старого пути сломали сборку. lewo: следует использовать Software Heritage как резервный архив для исходного кода — Nix и Guix уже реализуют подобный механизм, хотя Go mod не поддерживает SHA-проверку. imhoguy: предлагается использовать IPNS (IPFS) или распределённый реестр вместо доменов, чтобы избежать централизованных точек отказа при идентификации пакетов.