Не привязывайте свой Go-код к GitHub
Don't couple your Go code to GitHub
В Go импорты привязаны к URL хостинга, поэтому переезд с GitHub на GitLab требует правок в коде. Автор предлагает использовать собственный домен, например go.iain.rocks, и показывает конфигурацию Nginx и index.html с метатегом go-import. Такой подход избавляет от привязки к провайдеру и позволяет менять хостинг без изменения импортов.
В итоге ваш код оказывается буквально привязан к GitHub. Звучит совершенно безумно, но в сообществе Go это практически де-факто.
- jerf
Это прячется в обфускации излишней конкретности. Проблема общая. Чтобы назвать пакет, нужно находиться в каком-то пространстве имён. Поскольку вселенная не предоставляет никакого абстрактного внешнего «пространства имён», к которому мы все могли бы обратиться, все пространства имён — человеческие конструкты. Как человеческие конструкты, они могут отказать.
В этой терминологии статья по сути сводится к утверждению: «Это пространство имён может отказать! Решение — используйте другое!»
Но это никуда не ведёт, потому что новое пространство имён тоже может отказать. Фактически почти наверняка оно откажет раньше, чем «DNS и хостинг github.com» как пространство имён.
Не существует решения, в котором вы привязываете выпуск своего ПО к пространству имён, которое не может отказать, потому что не существует пространства имён, которое не может отказать. Неважно, использует ли ваш любимый язык DNS, или у него есть централизованно благословлённый репозиторий, или он распространяет благословлённый список имён пакетов вместе с самим языком, или что-то ещё. Пространство имён может отказать.
Следовательно, единственное, что вы действительно можете сделать, — быть устойчивыми к отказам, и во многих отношениях единственное практическое решение для устойчивости — просто предположить, что если в будущем у кого-то возникнут проблемы с получением пакета из-за отказа пространства имён, он не беспомощно растворится в луже слёз, пока ваш код потерян навсегда, а вместо этого будущий человек решит эту вполне решаемую проблему.
- rot256
Управление пакетами в Go всегда ощущалось довольно хакерским. Среди проблем — путаница между «что это такое» и «где это находится». В начале даже не было способа иметь разные версии пакета, с обоснованием, что нужно просто зафиксировать интерфейс и держать его стабильным до конца времён; также не было способа «зафиксировать зависимости», так что во время сборки вы получали то, что отдавал этот репозиторий. С тех пор стало лучше, но всё ещё есть некоторая корявость как результат «выращивания» пакетной системы.
- thih9
> На мой взгляд, каждая коммерческая команда разработчиков ПО, использующая Go, должна использовать собственные домены для пространств имён своих внутренних библиотек и пакетов.
Я бы убрал «Go» из вышесказанного, то есть считаю, что то же самое применимо и к другим стекам.
Даже использование ссылок на домен GitHub в комментариях к коду со временем становится проблематичным. Например, когда происходит миграция и эти ссылки начинают указывать в никуда.
- dewey
> То есть, если вы переносите свой git-хостинг на GitLab, вам приходится менять код!
Можно также просто использовать "replace github.com/example/example => gitlab.com/example/example" в вашем файле go.mod, и всё продолжит работать. Это выглядит как очень преждевременная оптимизация для того, что на самом деле не имеет значения.
- farthest
И что произойдёт, когда провайдера домена купят, а домен в вашем OSS-проекте выставят на аукцион и скомпрометируют? Похоже, это черепахи до самого низа...
- p4bl0
Верно, но остерегайтесь доменного имени, которое используете. Потому что VeriSign может в одностороннем порядке решить удалить ваш домен вместе с тысячами других [1], и вы вернётесь к исходной точке…
- unscaled
> Одна из хороших особенностей Go — вы задаёте пространство имён для кода с помощью местоположения для его загрузки.
А затем остальная часть статьи объясняет, почему на практике это НЕ хорошая особенность.
Я не думаю, что это неосуществимо, но это одна из тех мелочей, которые Go решил сделать иначе и убедил своих поклонников, что это отличная идея, а все остальные языки делают это неправильно. После пары появлений ухабов вместо признания, что есть некоторые преимущества в наличии официальных имён пакетов, нам теперь говорят, что каждый должен просто настроить свой собственный домен с nginx-сервером или форвардером Go Vanity URLs, чтобы обслуживать трафик для своих пакетов, размещённых на GitHub.
- st3fan
Отлично, когда компания закрывается и домены остаются висящими. Следующий, кто их подберёт, получает контроль над исходным кодом, от которого теперь зависят другие. Мы уже много раз видели это в других экосистемах. Это очень плохая ситуация.
Это плохой совет — переносить свои пакеты под собственный домен. Вы никогда не будете так же хороши, как Microsoft, в том, чтобы продолжать платить за домен. В жизни нет гарантий, но я гарантирую вам, что когда вы закроетесь, этот домен будет последним, о чём вы подумаете.