11-dependency-management.slide

Управление на зависимости
19.12.2018

fmi@golang.bg
http://fmi.golang.bg/
@fmi_golang

* Но преди това

- Разглеждаме проектите ви, съжаляваме че сме бавни
- Следващото домашно е зад ъгъла, честно

* Въпроси за мъфини

* Върпос #1

* Върпос #2

* Върпос #3

* Върпос #4

* Днес

- Работа със зависимости в Go
- Ще напишем кратък проект в час

* Зависимости?

Аз съм независим човек, не ми трябват!

* Зависимости

На кратко това е:

- Код писан от други хора, който искате да използвате

* Това е лесно! Нали?

- Да, "просто" използвам `go`get` и гото, нали?
- Често това е достатъчно
- Но още по - често не е

* Проблемите

- Наличност във времето
- Повторими build-ове

* Живота в свят след `leftpad`

- Какво става ако някоя ваша зависимост изчезне?
- Ами ако е нещо, от което зависят милиони хора?
- Контекст: [[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/][статия от времето на leftpad]]
- Изхвърляте кода си и започвате на ново?
- Има решение, за него по - късно.

* Повторими строежи

Задача!

Ако Иво и Дойчо build-нат commit на go проект, един и същи ли ще е резултата?

За нещастие - не.

* Неповторими build-ове?

Къде е проблемът?

- Някоя зависимост може да се е променила и `go`get` да вземе нова версия
- Стар код в `$GOPATH`
- При наличието на десетки зависимости лесно става много трудно

* Защо ни е това?

- Сигурност
- Quality Assurance

* О, това изглежда важно!

Значи има решение още от самото начало на езика, нали?

Само да можех да опиша кои версии точно искам!

Как се прави това? Нещо с `go` tool-а, нали?

* 😱

История

- В първите версии на Go нямаше нищо
- Авторите вярваха, че всички go developer-и ще могат да поддържат стабилни и backward compatible интерфейси, подобно на стандартната библиотека
- Реалният свят показа, че предположението не е вярно
- `Go1.5` добави The Vendor Experiment, от 1.6 е винаги включен
- Това позволява да си запазите вашите зависимости в хранилището, заедно с вашия код...
- ... като ръчно си копирате всички файлове там

* Иструментите

Това породи цяла зоогическа градина от иструменти, които го правят. Някои от тях:

glide, godep, govendor, vendor, godm, vendetta, gsv, gom, govend и много други

* Как работи това?

- Имате `vendor/` директория
- Когато види `gitlab.com/package/second` build tool-a ще потърси първо в `vendor/gitlab.com/package/second`
- Копирате си файловете от хранилището в тази директория
- Magic!

* dep

Известно време се използваше зоогическата градина от инструменти.

От Go екипа преди около 3 години решиха да направят официален "експеримент" - `dep`.

* daily dep

- Стъпва на [[https://semver.org][semver]]
- Хранилищата си слагат тагове `vX.Y.Z`
- В `Gopkg.toml` фай описвате какви версии искате
- `dep`ensure` ще попълни `vendor` директорията
- `dep`ensure`-add`<package>` за добавяне на нови пакети

* `Gopkg.toml` и `Gopkg.lock`

Първият държи какво желаете

Вторият държи кои точно версии са били намерени

* `Gopkg.toml`

    [[constraint]]
      name = "github.com/gorilla/mux"
      version = "1.6.2"

    [[constraint]]
      name = "github.com/howeyc/fsnotify"
      version = "0.9.0"

    [[constraint]]
      branch = "master"
      name = "github.com/ironsmile/sql-migrate"

* go modules

- В go1.11 вече имаме офицалия вариант
- ... който няма нищо общо с `dep`
- Експеримента все пак беше полезен
- Все още е зад флаг

* go modules (2)

- Част от `go` tool-a: `go mod`

* go modules (3)

    go mod init

- Създава `go.mod` файл със специален синтаксис
- Върши същото като Gopkg.toml
- След това `go`get` добавя в този файл
- `go`build` знае как да ги намери
- `go`mod`vendor` ги добавя в `vendor` директорията


* Demo