Последствия не использования пути репо для моих собственных пакетов

Question

Предположим, я решил сохранить все лично разработанные пакеты в следующем порядке:

$GOPATH/
    bin/
    pkg/
    src/
        somepkg1
        somepkg2
        ...
        somepkgN

Кроме того, предположим, что среди них много повторного использования кода, поэтому я решил оставить все рабочее пространство $GOPATH в одном и том же хранилище Git (каждый пакет может быть подмодулем), в отличие от более традиционного сценария, когда подпакеты менее согласованы (сосуществование исключительно из-за использования go get из той же рабочей области):

$GOPATH/
    bin/
    pkg/
    src/github.com/<me>/
        somepkg1
        somepkg2
        ...
        somepkgN

Я вижу, что с прежним подходом (не используя github.com/<me>/в путях к пакетам), go get не сможет получить пакеты, так как они не "объявляют" себя доступными онлайн. Тем не менее, можно легко обойти это, используя подмодули git, поэтому все пакеты будут извлечены в первую очередь (обратите внимание, что это строго контролируемая экосистема, поэтому не будет конфликтов имен).

Есть ли другие ограничения (кроме go get) не использовать полные пути для пакетов?

(В основном меня беспокоят ограничения, возникающие из-за определенных инструментов рефакторинга / анализа кода, использующих repository path as base path Конвенция, которая позволяет go get искать посылку онлайн.)

Answer 1

Для компилятора Go и всех элементов инструмента go, кроме go get путь импорта пакета - это почти непрозрачная строка, содержащая путь импорта. Вы можете выложить свой код так, как хотите (сам компилятор с радостью компилирует файлы из разных папок в один пакет). Если вам не нужен или вы хотите, чтобы ваш код был go getВ состоянии нет необходимости использовать путь репо. Инструменты анализа и рефакторинга в golang.org/x/tools работают на непрозрачных путях импорта (насколько я знаю) и не имеют доступа к сети.