neenik Oct 4 2020 at 00:11

Go: Как подключить внешнюю библиотеку и исключить ненужные зависимости

3 min

7.2K

Go*

Translation

Comments 9

borodyadka Oct 4 2020 at 09:11

Так почему бы не вынести драйвера в отдельный пакет?

import (
  "path.to/your/lib"
  "path.to/your/lib/drivers/postgres"
  // or
  "path.to/your/lib/drivers/json"
  // ...
)

Насколько помню, будут скачиваться только те зависимости, которые явно использованы.

neenik Oct 4 2020 at 09:53

Не всегда это получится. Например, в случае методов структуры как в nan

Это для json

func (n *NullBool) UnmarshalJSON(data []byte) error {
}

А это для sql

func (n *NullBool) Scan(value interface{}) error {
}

qw1 Oct 11 2020 at 07:05

Как вариант, поиграться с условной компиляцией
go build -tags mylib_withpostgress
Пользователь библиотеки должен явно указывать tags при сборке своего проекта.

neenik Oct 11 2020 at 10:37

Хорошее дополнение, как один из вариантов решения, когда надо исключить зависимости на уровне компиляции. Единственно, что на уровне исходного кода зависимости останутся.

qw1 Oct 11 2020 at 11:29

Не обязательно.

Например, в проекте есть файл mylib_postgress.go, у которого в в начале файла
// +build mylib_withpostgress

И есть файл mylib_postgress_dummy.go, у которого в в начале файла
// +build !mylib_withpostgress
который полностью описывает те же интерфейсы и реализации, что и первый файл, но не обращаясь к либам постгресса, а просто выкидывая panic в каждом методе.

neenik Oct 11 2020 at 11:35

Я имею в виду, что зависимости на уровне исходного кода никуда не денутся.

Как в вашем примере — в go.mod будут зависимости от postgres из mylib_withpostgress. И, если используется, в vendor.

qw1 Oct 11 2020 at 11:38

Вот в каком смысле, тут согласен.

qw1 Oct 11 2020 at 11:39

А какие минусы? Как указали выше, неиспользуемые зависимости не скачиваются.

neenik Oct 11 2020 at 14:40

Минусов но, но тут мне кажется, что зависит от юзкейза. Где-то так, где-то так хочется.