GoLang: Модули Go в реальной жизни
Прочитал статью Go Modules In Real Life (Chip Keyes, 06.2019г.). В ней описываются ситуации нюансы использования модулей GO в разработке.Модули Go появились с версии 1.11 и позволяют уйти от жесткой привязке к GOPATH. Чем же еще это полезно и как и когда их использовать?
Краткая выжимка:
1. Модуль - это коллекция пакетов GO объединенных в одну общую единицу.
2. Причины по которым вы можете захотеть сделать пакет модулем:
- мы хотим содержать и версировать код отдельно от других частей приложения;
- мы хотим использовать этот код более чем в одном проекте или поделиться с обществом;
- у нас в монорепозитарии кодовая база, содержащая одну или несколько программ.
3. В одном репозитарии могут жить несколько версий модуля.
Самый простой пример модуля который может использоваться во многих проектах - логгер.
4. Импорт модуля в проект.
Вариант 1: опубликовать код на github.com, создать метку с номером выпущенной версии модуля. Если репозитарий закрытый, то при импорте go get нужно будет указать параметры аутентификации. Это подходит в большинстве случаев. Однако минус в том, что нужно строго размещать один модуль в одном репозитарии, чтобы создавать ветки (tag) релизов.
Вариант 2: многомодульный репозитарий и использование слова `replace` в go.mod (оно говорит Go, где искать модуль относительно go.mod файла, чтобы найти его локально). Например в проекте вы подключаете модуль `import "my_project/logger"`, но компилятор не может его найти «cannot load my_project/logger: cannot find module providing package my_project/logger», т.к. он есть только локально, а Go пытается найти его по url. Тогда укажем, где искать модуль локально, в go.mod добавим `replace my_project/logger => ../logger`. Теперь при сборке Go перейдет на каталог выше (в my_project) и найдет там каталог модуля `my_project/logger`
Краткая выжимка:
1. Модуль - это коллекция пакетов GO объединенных в одну общую единицу.
2. Причины по которым вы можете захотеть сделать пакет модулем:
- мы хотим содержать и версировать код отдельно от других частей приложения;
- мы хотим использовать этот код более чем в одном проекте или поделиться с обществом;
- у нас в монорепозитарии кодовая база, содержащая одну или несколько программ.
3. В одном репозитарии могут жить несколько версий модуля.
Самый простой пример модуля который может использоваться во многих проектах - логгер.
4. Импорт модуля в проект.
Вариант 1: опубликовать код на github.com, создать метку с номером выпущенной версии модуля. Если репозитарий закрытый, то при импорте go get нужно будет указать параметры аутентификации. Это подходит в большинстве случаев. Однако минус в том, что нужно строго размещать один модуль в одном репозитарии, чтобы создавать ветки (tag) релизов.
Вариант 2: многомодульный репозитарий и использование слова `replace` в go.mod (оно говорит Go, где искать модуль относительно go.mod файла, чтобы найти его локально). Например в проекте вы подключаете модуль `import "my_project/logger"`, но компилятор не может его найти «cannot load my_project/logger: cannot find module providing package my_project/logger», т.к. он есть только локально, а Go пытается найти его по url. Тогда укажем, где искать модуль локально, в go.mod добавим `replace my_project/logger => ../logger`. Теперь при сборке Go перейдет на каталог выше (в my_project) и найдет там каталог модуля `my_project/logger`