Можно ли использовать go mod tidy для очистки неиспользуемых зависимостей, кроме косвенных?

Я понимаю, что это ожидаемое поведение go mod tidy при сокращении дерева зависимостей путем удаления ненужных, но часть моего CI использует go-swagger для создания файлов swagger JSON. Итак, в конце концов. go mod tidy удалит go-swagger пакеты из go.mod файла, потому что они указаны как //indirect (они не используются непосредственно из исходного кода). Есть ли обходной путь?

Вот мой go.mod файл:

...
require (
    github.com/go-openapi/errors v0.20.0 // indirect
    github.com/go-openapi/validate v0.20.2 // indirect
    github.com/go-swagger/go-swagger v0.26.1 // indirect
    github.com/gorilla/mux v1.8.0
    github.com/mailru/easyjson v0.7.7 // indirect
    github.com/spf13/afero v1.5.1 // indirect
    golang.org/x/mod v0.4.1 // indirect
    golang.org/x/net v0.0.0-20210220033124-5f55cee0dc0d // indirect
    golang.org/x/sys v0.0.0-20210220050731-9a76102bfb43 // indirect
    golang.org/x/tools v0.1.0 // indirect
)

После запуска go mod tidy останется только этот:

    github.com/gorilla/mux v1.8.0

Однако у меня есть следующая цель в моем Makefile, работающем в производственной среде:

$ swagger generate spec -o ./internal/ui/swagger.json

Я как бы хотел избежать явных вызовов go get на go-swagger глобально после запуска go tidy. У вас есть какие-нибудь предложения, как это обойти?


person phramos07    schedule 21.02.2021    source источник


Ответы (1)


Я подозреваю, что одним из обходных путей было бы:

  • явно импортируйте в один из исходных файлов проекта .go файл пакета github.com/go-swagger/go-swagger/scan
  • define a dummy variable
    var _ = scan.Parse
    

Таким образом, ваши источники будут напрямую использовать github.com/go-swagger/go-swagger, который больше не будет сокращаться с помощью go mod tidy.

Я бы сделал это в файле go с именем externalTools.go, просто чтобы помнить, зачем этот поддельный импорт.

person VonC    schedule 21.02.2021