Комментарии 18
Меня честно говоря удивляет то, что в golang такой ограниченный package manager по умолчанию. Не удивляюсь, почему наплодили столько tools github.com/golang/go/wiki/PackageManagementTools
Тому есть несколько причин:
1. Любой уважающий себя рубист/питонист, будучи полным «не очень» с go, будет желать написания своего любимого bundler'a/pip'a etc на go
2. Было время когда на golang'e было написано много посредственного кода «без фатальных недостатков» как у других, просто потому что людей которые могли написать что-то «более-менее» ещё не было в природе.
Вот Дейв Чейни — один из немногих, который знает как делать правильно, и в итоге в gb есть не только хорошая сборка и менеджмент зависимостей, но и оптимизации флагов сборки для каждой версии golang'a.
1. Любой уважающий себя рубист/питонист, будучи полным «не очень» с go, будет желать написания своего любимого bundler'a/pip'a etc на go
2. Было время когда на golang'e было написано много посредственного кода «без фатальных недостатков» как у других, просто потому что людей которые могли написать что-то «более-менее» ещё не было в природе.
Вот Дейв Чейни — один из немногих, который знает как делать правильно, и в итоге в gb есть не только хорошая сборка и менеджмент зависимостей, но и оптимизации флагов сборки для каждой версии golang'a.
Почему удивляет? Добрая половина данной статьи объясняет причину этого :)
А есть эквивалент команды
Или для каждой зависимости нужно делать
go get ./...
Или для каждой зависимости нужно делать
gb vendor fetch foo.com/bar/baz
Пока что нужно делать, но скоро такая фича будет: github.com/constabulary/gb/issues/139
Зачастую, когда Go используется только для одного проекта, рекомендуют подход «GOPATH per project» — фактически, вас просят поменять ваш GOPATH на путь к данному проекту и работать в нём. gb реализует что-то подобное, только не трогая ваш системный GOPATH.
Но ведь основной GOPATH и не нужно заменять, его можно просто дополнить
export GOPATH=$HOME/Go:$HOME/projectВсе так, но это источник труднодиагностируемых проблем — к примеру, если в project/ у вас более новая версия пакаджа и вы подразумеваете, что работаете с ним, а на самом деле он берется из первого GOPATH. Или, новый разработчик в тиме, забыл/не понял установить два GOPATH и собирает проект, а код берется не завендоренный, а из его GOPATH. Там много всего может быть, поэтому множественный GOPATH и не рекомендуют в общем случае.
go get github.com/constabulary/gb/...
По непонятной для меня причине программистов на маках тянет к слаке
Эм… Какая связь между go get, маками и слакой?
Потому, что срач в /usr это традиция слаки. Автор как бы намекает, что правильно было бы каждая зависимость аккуратно упакована в своей пакет и доступна везде. А не 9001 минорная версия одного и того же пакета для каждой программы на Go (по коммиту на каждый пакет).
Вот gem из руби позволяет иметь несколько версий одного и тожего же пакета в системе, bundler решает проблемы чтобы в приложении была только одна версия пакета (пример npm где каждая зависимость тянет все зависимости локально для себя).
Maven (а так же остальные) решает проблему тоже весьма интересным способом.
А что делает Go? «Вот тебе GOPATH ты его меняй на каждый проект и все будет хорошо» В результате пакеты (тут я уже про .dev, .rpm, pkgng) становятся толстыми ибо каждый раз надо все зависимости с собой паковать.Я раньше тоже не понимал зачем в портах фряхи руби гемы лежат, теперь понял.
Вот gem из руби позволяет иметь несколько версий одного и тожего же пакета в системе, bundler решает проблемы чтобы в приложении была только одна версия пакета (пример npm где каждая зависимость тянет все зависимости локально для себя).
Maven (а так же остальные) решает проблему тоже весьма интересным способом.
А что делает Go? «Вот тебе GOPATH ты его меняй на каждый проект и все будет хорошо» В результате пакеты (тут я уже про .dev, .rpm, pkgng) становятся толстыми ибо каждый раз надо все зависимости с собой паковать.Я раньше тоже не понимал зачем в портах фряхи руби гемы лежат, теперь понял.
Мне кажется, или вы только что попытались сказать «Все вопросы менеджмента зависимостей — легко и просто решаются, но авторы и коммьюнити Go просто не знают того, что знаю я про опыт других языков, и поэтому сделали неправильно»? :)
Нет, я ответил на ваш вопрос «Какая связь между go get, маками и слакой?»
А так же возмутился тем, что все пытаются решить проблему зависимостей, а ребята из go решили не решать ее и сказать «да будет срач»
А так же возмутился тем, что все пытаются решить проблему зависимостей, а ребята из go решили не решать ее и сказать «да будет срач»
Ну, во-первых, не ответили. ) В оригинальном комментарии была процитирована строка запуска go get и вот та фраза про связь. Даже оставив в стороне про «срач в /usr» и GOPATH (тут я еще могу ход мысли проследить), но причем тут маки?
Ваше возмущение мне более-менее понятно, но они да, решают, проблему, и стадия «посмотреть что и как нужно всем» — это тоже часть решения. Это же не арифметическая задача, здесь вопрос компромиссов и не впаривать всем решение «удобное для нас» — достаточно разумно.
Ваше возмущение мне более-менее понятно, но они да, решают, проблему, и стадия «посмотреть что и как нужно всем» — это тоже часть решения. Это же не арифметическая задача, здесь вопрос компромиссов и не впаривать всем решение «удобное для нас» — достаточно разумно.
Притом, что на маках это принято так делать? «chown -R `whoami` /usr» Наверное первое, что програмист который пользуется маком пишем в своем терминале. Вы не знаете менталитет пользователей слаки?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
gb — менеджмент зависимостей для Go