Go (golang) - современный язык программирования, предназначенный для разработки высококонкурентных приложений, работающих на многопроцессорных системах. В данной части курса будут обзорно рассмотрены типовые задачи, возникающие перед разработчиком любого веб-сервиса и способы их решения на Go. Это курс предназначен для людей с опытом в веб-программировании. Если вы пишете на PHP/Python/Ruby/JS (Node.js) и хотите освоить Go - этот курс для вас. Начинающим программистам может быть немного сложно, т.к. в лекциях используется профессиональный жаргон (сленг), без детальных пояснений. Курс не рассчитан на людей без опыта программирования.
Утилита dep
Loading...
Из курса от партнера Moscow Institute of Physics and Technology
Разработка веб-сервисов на Golang, часть 2
64 оценки
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
Из урока
Анатомия веб-сервиса
В этой лекции мы поговорим про самые частые компоненты, которые встречаются при разработке веб-сервисов
Познакомьтесь с преподавателями
Романов Василий ВячеславовичSoftware engineer
Mail.Ru Group
[БЕЗ_ЗВУКА] В
этом видео мы поговорим про организацию зависимостей,
то есть внешних пакетов с кодом, которые требуются вашему приложению.
Во многих других языках зависимости устанавливаются через разного
рода менеджеры пакетов либо как какие-то прямо внешние отдельные пакеты,
например rmp или deb.
Либо же используется в Node.js, например, rmp.
В других языках есть аналогичные инструменты,
например pip в Python либо RubyGems.
В Go есть тоже встроенный инструмент для подтягивания внешних пакетов — go get.
Вы уже много раз его видели и наверняка уже даже пользовались.
Однако есть и большой нюанс: он устанавливает все эти зависимости в
одну папку GOPATH.
Почему это имеет значение?
Потому что если вы работаете над несколькими проектами,
у вас могут отличаться зависимости, которые нужны для этих проектов.
Например, где-то нужны новые возможности,
но там сломана обратная совместимость, а вы не хотите тратить время на починку
старого проекта — он уже работает и не стоит там ничего менять.
Как быть, что делать?
Есть первый вариант, самый такой в лоб — это менять GOPATH.
То есть вы можете в env переустановить значение этой
переменной, и новый пакет устанавливать в другое место.
Но это не очень переносимо и требует для удобства какой-нибудь Makefile,
например, чтобы он там внутри переопределял все и прочее.
Вот.
Поэтому в рабочей,
в рабочей группе Go работают над тем, какие инструменты предоставить.
Пока они работают, уже родилось несколько менеджеров зависимостей,
которые ставят все зависимости в папку vendor.
И, вообще, работа зависимости в Go называется vendoring.
Рассмотрим следующий код.
Собственно, сам код не нужен, тут я использую grpc,
пытаясь запустить какой-то сервер.
go run main — и он мне говорит: оп,
не получается запустить сервер, потому что нет пакета,
нет grpc установленного, ни в GOROOT, ни в GOPATH, нигде.
При этом что у меня лежит?
У меня лежит только файл main и какой-то еще glide.
Поэтому первым — вот, собственно, мой файл.
И вот glide.md — это первый менеджер зависимостей, про который мы поговорим.
Что — в нем нет особо ничего примечательного,
он может просканировать — нет, не хочу.
Он может просканировать ваш ваш код на предмет тех зависимостей,
которые там используются, и построить glide-файл.
Например, смотрите, вот получился мой glide.yaml.
Откроем его, и вот что мои зависимости
требуют — что пакет такой-то требует зависимости вот такой, grpc.
Теперь я могу сделать установку этих зависимостей: либо через glide get,
либо через glide install, который поставит мне все зависимости.
Вот. Теперь я подожду какое-то время,
пока он подтянет вообще все зависимости.
Он подтянет их, включая зависимости от вашей зависимости,
то есть всю цепочку, все поддерево.
Куда он их положит и как это будет запускаться?
Дело в том, что в Go пришли к такому решению,
что если рядом с вашим кодом, который вы запускаете,
есть папка vendor — в данный момент в нее скачиваются зависимости; о,
уже скачались, — то тогда код, который использует эти зависимости будет искать их
в первую очередь в этой папке, а не в GOROOT и GOPATH.
Итак, что у нас появилось?
glide.yaml вы уже видели, появился glide.lock.
glide.lock — там есть все
зависимости, хеш- версия этой зависимости,
гетовая, откуда идет, подпакеты и прочее.
Вот. И появился, появилась директория vendor,
где все эти зависимости уже скачаны, уже лежат.
Теперь если я запущу свою программу, которая ранее мне ругалась на то,
что нет зависимости, она найдет эту зависимость в папке vendor — напомню,
вот она появилась рядом с моим файлом — и успешно запустится.
[ШУМ] Вот, запустилась, все хорошо.
То есть теперь мой пакет использует зависимости из этой папки.
Другие зависимости могут быть найдены либо опять-таки в этой папке,
либо в общем GOROOT, в общесистемной папке.
Итак, но есть нюансы.
То есть да, зависимости все подтягиваются, однако подпакеты, subpkg,
подтянуть не получится — вам придется использовать полный путь
для обращения к этому пакету там, где он действительно должен лежать.
Но либо вы можете, конечно, сделать вот так, но это не очень рекомендуется.
Это был glide.
Менеджеров зависимости довольно много.
Теперь рассмотрим еще один.
Рассмотрим еще один, называется он dep.
dep — это будущий стандартный менеджер зависимостей,
сейчас он находится в, скажем так, зачаточном состоянии,
то есть он умеет некоторые вещи, но не все.
Функционал его похож на glide, похож на другие менеджеры.
То есть у него тоже есть функция dep init, которая тоже просканирует ваш код на
предмет того, какие там зависимости нужны, какие зависимости стоит установить.
Делает он это какое-то время.
И, собственно, от glide он уже не будет
отличаться — ну, будет отличаться, но не так много, не так сильно.
Он так же хранит список зависимостей, так же хранит версии этих зависимостей.
А, вот, отлично.
Все нашел, все установил, все скачал.
Посмотрим: уже и папка vendor появилась, и Gopkg появился.
glide мы закроем.
Вот файл, который создал dep,
вот мои зависимости, grpc.
Вот все версии, которые там лежат и с хешами всех зависимостей.
dep — инструмент молодой, там еще нет всех тех возможностей,
которые есть в glide или govendor, godep, который слитно пишется.
Но это будущий стандартный менеджер зависимостей и знать по него стоит.
Так, это dep.
То есть все зависимости теперь лежат у вас.
И еще один менеджер, который мы рассмотрим, называется gb.
Как вы видели все — давайте я переключу обратно,
— все предыдущие примеры у меня были внутри моего GOPATH,
то есть HOME и go, и я жил там.
Но в свое время был разработан Dave Cheney еще один
менеджер зависимости, называется gb.
gb вот так просто называется,
он внутри себя перекрывает GOPATH и позволяет вам работать с каждым
из ваших проектов действительно полноценно в отдельной директории.
Для этого у него есть свои команды, gb build.
Да, вот смотрите.
Так, сервер.
А, да.
Теперь он не смог найти опять grpc, я должен поставить его руками.
Он не очень активно развивается, хотя автор обещает возобновить над ним работы.
Так, теперь я должен поставить grpc, он еще не умеет сам сканировать
файлы на предмет тех зависимостей, которые ему нужны.
Ставим, пытаемся выключить рекурсивно все,
что там есть, и точно так же он записывает их в файл.
Однако он делает немножко по-другому — он не записывает это в папку vendor,
а у него другой подход — у него папка vendor, а там уже папка src.
И весь ваш код, он тоже находится в папке src.
Сейчас он закончит скачиваться, я вам покажу.
gb — у него тоже есть свои нюансы, он, например,
не может подтягивать из защищенных, из защищенных
источников, когда у вас ваш
репозиторий закрыт, не публичный, а закрыт сертификатом, например.
То есть эти зависимости подтянуть через него не так просто,
поэтому приходится прописывать в файле руками.
Да, gb работает не так шустро,
как остальные поэтому мы еще ждем, мы еще ждем.
Какой плюс есть у gb?
В чем его удобство?
Дело в том, что в случае gb вы можете нормально,
полноценно использовать subpkg,
то есть те пакеты, которые идут прямо от корня вашего сервера,
то есть вам не придется писать cousera
или github, что-то там, pkg.
Он будет видеть этот пакет непосредственно из из корня.
Так, вроде бы почти закончилось.
В связи с этим gb
бывает удобен для совсем изолированных сервисов,
которые вы не хотите класть в свой, в свой GOPATH.
Итак, отлично — gb наконец-таки выкачал все зависимости.
Посмотрим.
Итак, у нас просто появилась папка vendor.
И внутри vendor уже теперь лежат все зависимости.
Манифест с версиями, в src лежат сами исходники,
а в папке src, которая лежит в корне нашего проекта,
лежат уже исходники нашего приложения, как раз subpkg.
Теперь я могу набрать go build, gb build простите.
И он соберет мне все мое приложение уже из этой папки.
Обратите внимание, у меня появилась директория pkg,
где лежат временные объектные файлы и bin.
Теперь, если я захочу запустить свой сервер, я запускаю его из из bin.
gb не поддерживает go run,
то есть у него нет такого формата, просто сразу компиляция.
И, соответственно, я в нем смог получить доступ к subpkg-пакету
не по полному пути, а прямо из корня.
Вот такое разнообразие пакетных менеджеров в Go.
Конечно, есть и другие, это не полный список.
Кому-то понравится glide, кому-то dep,
кто-то выберет gb, кому-то еще придется по душе govendor.
Это нужно все смотреть и пробовать на себе.
Но я все-таки жду, когда можно будет подгружать зависимости прямо из той папки,
где они находятся, без плясок с бубном, как это сделано в gb.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2019 Все права защищены.
