Проблемы с 'go build' в разветвленном хранилище

Question

Я создаю двоичный файл для репозитория GitHub (код go), который отлично работает.без вопросов.Я раздвоил это репо и изменил одну строку в HTML-файле, которая не имеет ничего общего с кодом GO, построил двоичный файл для нового разветвленного репо, но генерируемый бинарный файл ссылается на исходный код репо, не могу понять, почему.

Я даже очистил весь код с помощью команды go clean -i all и вручную удалил весь установленный код, двоичные файлы из $ home / go / bin и каталог репо, но он по-прежнему ссылается на исходный код репо вместоновый раздвоенный код.

---

На основе решения, предложенного Тобиасом, я выполнил следующие шаги:

После этого я выполнил go buildв этом каталоге репо, но новый двоичный файл все еще ссылается на старый код.Я даже удалил старый двоичный файл и сгенерировал новый.

Answer 1

Проблема с раздвоенной копией пакетов go заключается в том, что когда пакет действительно состоит из нескольких пакетов go в одном репо, операторы импорта ссылаются на исходное базовое репо, то есть: github.com/orig/repo.

Это непроблема для репозиториев с одним пакетом go, поскольку он никогда не ссылается на себя.

Но если он имеет несколько, то есть: package github.com/orig/repo/A import github.com/orig/repo/B

И тогда вы разветвляете его как: github.com/fork/repo

Затем, когда компилятор go видитimport "github.com/orig/repo/B" в исходном коде, идет загрузка исходной версии, а не вашего форка.

К счастью, go modules решает эту проблему.

По сути, создайте go.mod в верхней части вашего разветвленного репо и добавьте: module github.com/orig/repo

, тогда компилятор go будет считать, что вы «orig / repo» независимо от того, откуда вы на самом деле выписаны.

поэтому, когда orig/repo/A импортирует orig/repo/B, он будет выглядеть локально.

Если есть другие операции импорта, которые необходимо переопределить и которые находятся за пределами основного разветвленного репо, вы также можете принудительно установить зависимости из другого места.используя заменить

Answer 2

решено

Сначала я подумал, что это проблема с FORK (что является распространенной проблемой, возникающей при использовании форка репозитория языка Go), но, оказывается, это было специфично для репопроблема.Для работы разветвленного репо необходимо было переустановить одну из зависимых библиотек, что не было упомянуто в оригинальной документации репо.Наконец, эта ссылка помогла: https://github.com/inconshreveable/ngrok/issues/181#issuecomment-65646229, проблема была не общей, а специфичной для репозитория. Я выполнил приведенную ниже ссылку, чтобы устранить зависимость от go-bindata

go get github.com/jteeuwen/go-bindata
cd $GOPATH/src/github.com/jteeuwen/go-bindata/go-bindata
go build

Answer 3

Это распространенная проблема в го.Система ссылок в «расположении на основе», поэтому она ищет эти файлы по «правильному» пути.Idk, если go-модули решают эту проблему, но, по крайней мере, если вы не используете go-модули, вам придется обойти это.

Вы можете решить эту проблему с помощью

Решение 1

1. Загрузите исходный репозиторий, который вы разветвили:

go get http://github.com/awesome-org/tool

Добавьте ваш форк как удаленный

git remote добавьте awesome-you-fork http://github.com/awesome-you/tool

Вам нужно будет внести изменения в папку исходного загруженного репо и Push and Pull на / с вашего форка.

git pull - rebase awesome-you-fork

git push awesome-you-fork

Solution 2

Обходите иди: Вы создаете путь, по которому будет исходный репо, но клонируете в него свой собственный форк.Таким образом, вы можете толкать и тянуть к вилке.Это может быть лучшее решение

cd $GOPATH
mkdir -p {src,bin,pkg}
mkdir -p src/github.com/awesome-org/
cd src/github.com/awesome-org/

git clone git@github.com:awesome-you/tool.git # OR: git clone https://github.com/awesome-you/tool.git
cd tool/
go get ./...

Эти решения были найдены здесь: http://code.openark.org/blog/development/forking-golang-repositories-on-github-and-managing-the-import-path