V
Ну вот, уже без вендор неймспейса. Как в рубишечке. Придётся с этим жить.
Size: a a a
2020 April 15
V
а ведь можно поднять свой hex, адрес хекса не играет роль VendorNamespace?
Нет, это не то же самое
LL
Ну, форки можно указывать напрямую с
githubLL
А какая тогда разница между
github и hexpmAB
А какая тогда разница между
github и hexpmБилд быстрее, например. :)
LL
Билд быстрее, например. :)
Так и там и там сорцы качаются, просто с
github на пару секунд быстрееRS
с hexpm мастер/нужную ветку не скачаешь, если что
LL
с hexpm мастер/нужную ветку не скачаешь, если что
Про это и разговор...
AB
А вообще, это несовпадение языков разработки и управления пакетами, что довольно сомнительная идея.
Я сейчас вот так сразу пример не приведу, но когда это станет проблемой, она будет очень болезненной
Я сейчас вот так сразу пример не приведу, но когда это станет проблемой, она будет очень болезненной
LL
Но в
hex.pm есть версии, вот версии и обычно и указываютсяLL
А вообще, это несовпадение языков разработки и управления пакетами, что довольно сомнительная идея.
Я сейчас вот так сразу пример не приведу, но когда это станет проблемой, она будет очень болезненной
Я сейчас вот так сразу пример не приведу, но когда это станет проблемой, она будет очень болезненной
> несовпадение языков разработки и управления пакетами
Поясни
Поясни
AB
Блин, я не знаю, как это лучше назвать.
В разработке сейчас стандартом является возможность децентрализации и наличия нескольких отличающихся "голов" от разных авторов у куска кода. Это не всегда хорошо и не всегда нужно, но это есть.
А с другой стороны люди продолжают делать менеджеры пакетов, где эта сторона реальности не отражается. Обеспечивающая система, не отражающая реалии целевой.
В разработке сейчас стандартом является возможность децентрализации и наличия нескольких отличающихся "голов" от разных авторов у куска кода. Это не всегда хорошо и не всегда нужно, но это есть.
А с другой стороны люди продолжают делать менеджеры пакетов, где эта сторона реальности не отражается. Обеспечивающая система, не отражающая реалии целевой.
P
Скромно шебуршит go.mod в уголке
S
Ад с зависимостями всегда был и будет на мой взгляд. Возможность брать напрямую с гита это как раз решение этого ада, пусть и не идеальное. Особенно весело реанимировать проект который на пару тройку лет выпал из обоймы
AB
Скромно шебуршит go.mod в уголке
пока в го не выпилят git url из импортов - это гугловский внутренний дсл, а не язык общего назначения
MS
пока в го не выпилят git url из импортов - это гугловский внутренний дсл, а не язык общего назначения
Что не мешает на нем различные проекты писать
P
пока в го не выпилят git url из импортов - это гугловский внутренний дсл, а не язык общего назначения
Правильно, надо переходить на mercurial
AB
меркуриал проиграл почему-то
A
@nwalker мне пока завязанность в Го на гитхаб нравится. Проблема в релизинге артефактов (я сюда не допыхтел)?
PG
погодите, как го завязан на гитхаб?