tl; dr;
Преобразование сборки большого проекта из GOPATH в go modules - так что я могу жестко принудительно управлять версиями пакетов. Это преобразование выполнено на 95%, но он столкнулся с неприятным крайним случаем унаследованного стороннего пакета, который кажется несовместимым со сборками типа go modules.
Проблему сборки можно легко воспроизвести с помощью этого фрагмента :
package iamstuck
import _ "github.com/vjeantet/goldap/message" // <- 5+ years old i.e. pre-go-modules
Построение этого приводит к следующей ошибке:
$ go mod init iamstuck
$ go build; echo RC=$?
go: finding module for package github.com/vjeantet/goldap/message
iamstuck.go:3:8: no matching versions for query "latest"
RC=1
Попытка вручную извлечь последнюю версию фиксации, также завершается неудачей:
$ go get github.com/vjeantet/goldap/message
go get github.com/vjeantet/goldap/message: no matching versions for query "upgrade"
Выше компилируется при использовании директивы GOPATH или non-go -modules:
$ GO111MODULE=off go build ; echo RC=$?
RC=0
При некоторых поисках в Google обнаруживается go проблема 28001 : с причиной root, предположительно являющейся недопустимый символ : в некоторых пакетах do c имена файлов - поэтому ничего общего с файлами пакета go -кода!
Так что мой вопрос: можно ли перемещаться вокруг этой go modules проблемы сборки без изменения стороннего пакета? может быть, какая-то специальная директива go.mod?
Я бы не хотел раскошелиться на этот репо. Я также использую родительский пакет github.com / vjeantet / ldapserver , который импортирует / ссылается на проблему c github.com/vjeantet/goldap/message. Таким образом, этот пакет необходимо будет также разветвлять / обновлять. Так что это становится очень грязным ...
Поскольку этот проект и зависимости компилируются с использованием GOPATH - я чувствую, что должна быть какая-то директива, которую я могу использовать в go.mod, чтобы обойти эту проблему?