Скачал с гитхаба несколько интересующих меня проектов, изучаю код.
В проекте несколько "пакетов" — т.е. папок, в каждой папке-пакете несколько файлов, в начале каждого файла — инструкция package имя_пакета, где имя_пакета совпадает с именем папки. Ну допустим это так принято.
В секциях import подключаются пакеты — встроенные в Go и какие-то с гитхаба. И вот что непонятно
1. Прежде всего, мне попадается довольно много проектов, в которых наподключена куча всего с гитхаба. Это теперь так принято — доверять непойми чьему коду? Я понимаю в С++ существуют некие общепринятые библиотеки типа Буста, да и то во многих случаях их стараются избегать. А в Go другая философия? Есть ли хотя-бы какие-то "курируемые списки" хороших библиотек (желательно курируемые самими разработчиками языка)?
2. Самое главное что непонятно — пути к собственным пакетам (т.е. тем, код которых включен в проект и написан тем же автором) тоже организованы через гитхаб.
В результате go, вместо того чтобы использовать локальные исходники, которые лежат тут же рядом, скачивает их с гитхаба, кладет в какую-то мутную папку вида c:/Users/<username>/go/pkg/mod, и компилирует оттуда.
Вот сейчас прошелся по всем исходникам проекта и заменил пути вида github.com/UserName/RepoName/PackageName на ModuleName/PackageName, где ModuleName — это просто имя моего проекта, указанное в go.mod. И все компилируется, но теперь (как я понимаю) исходники пакетов будут браться локально, и я смогу исправлять их также локально вместе с исходниками главного (исполняемого) пакета.
Прав ли я? И если да, то как предполагается работать над кодом библиотек, если бы я такое не сделал — постоянно синхронизировать с гитхабом перед компиляцией? (но в такое я как-то совсем не верю). Или эти пакеты как-то синхронизировались бы локально сами (между рабочей папкой и той что на c:/users)? Или я вообще чего-то здесь не понимаю.
Мне вообще нравится концепция, когда исходники полностью самодостаточны и полностью компилируются на машине без интернета. Но здесь похоже все наоборот...
Здравствуйте, 00011011, Вы писали:
0>1. Прежде всего, мне попадается довольно много проектов, в которых наподключена куча всего с гитхаба. Это теперь так принято — доверять непойми чьему коду?
Да.
> Есть ли хотя-бы какие-то "курируемые списки" хороших библиотек (желательно курируемые самими разработчиками языка)?
Нет. Можешь смотреть на число звёздочек на гитхабе
0>Мне вообще нравится концепция, когда исходники полностью самодостаточны и полностью компилируются на машине без интернета. Но здесь похоже все наоборот...
Запусти go mod vendor и все зависимости скачаются в папку vendor
Здравствуйте, vsb, Вы писали:
vsb>Запусти go mod vendor и все зависимости скачаются в папку vendor
Так если часть зависимостей уже скачалась вместе с исходниками?
Их проще удалить чтобы не путаться?
Или это особенности мышления автора проекта, который сделал отдельными пакетами "controllers", "models", "helpers" и тому подобное, и зачем-то прописал к ним пути через гитхаб, хотя все это просто лежит в папочках рядом с main.go? Я вот этого не понимаю...
>> Есть ли хотя-бы какие-то "курируемые списки" хороших библиотек (желательно курируемые самими разработчиками языка)?
vsb>Нет. Можешь смотреть на число звёздочек на гитхабе
Справедливости ради, есть курируемые списки в awesome-go.
Здравствуйте, 00011011, Вы писали:
vsb>>Запусти go mod vendor и все зависимости скачаются в папку vendor
0>Так если часть зависимостей уже скачалась вместе с исходниками? 0>Их проще удалить чтобы не путаться? 0>Или это особенности мышления автора проекта, который сделал отдельными пакетами "controllers", "models", "helpers" и тому подобное, и зачем-то прописал к ним пути через гитхаб, хотя все это просто лежит в папочках рядом с main.go? Я вот этого не понимаю...
Я честно говоря не очень в курсе, но таких проблем, которые ты описываешь, не испытывал.
На всякий случай посоветую ознакомиться с go modules. Раньше немного по-другому было.
Здравствуйте, 00011011, Вы писали:
0>Или это особенности мышления автора проекта, который сделал отдельными пакетами "controllers", "models", "helpers" и тому подобное, и зачем-то прописал к ним пути через гитхаб, хотя все это просто лежит в папочках рядом с main.go? Я вот этого не понимаю...
Нет, не так.
Вот есть у тебя модуль (см. проект — отдельная независимая сущность). У неё есть название, задаётся при старте написания этого модуля командой
go mod init <module_name>.
module_name может быть любым (от слова вообще), но если планируется хранить исходники на гитхабе, то это будет github.com/UserName/RepoName/PackageName.
У модуля, естественно будут появляться подмодули, соответственно в поддиректориях., чтобы их импортировать, нужно указывать полный путь до подмодуля, включая module_name. То, что module_name имеет формат <путь до github>, не означает, что он должен синхронизироваться через github.
Внешние для модуля зависимости будут скачиваться в тайную директорию гошки, но их можно скопировать к себе в проект командой go mod vendor.
Дело в том, что go get работает через git, и, чтобы иметь свои общие модули, которые хочется импортировать в свои — же разные проекты, то их называют именем пути к репозиторию. Это хорошо работает с github, а вот, например, с gitlab, с его группами и подгруппами, уже нет.
Я в своих игрушках общий код вообще оформляю в виде репозиториев с только .go файлами (не модули), и подключаю через git submodules.
Здравствуйте, Doom100500, Вы писали:
D>module_name может быть любым (от слова вообще), но если планируется хранить исходники на гитхабе, то это будет github.com/UserName/RepoName/PackageName.
D>У модуля, естественно будут появляться подмодули, соответственно в поддиректориях., чтобы их импортировать, нужно указывать полный путь до подмодуля, включая module_name. То, что module_name имеет формат <путь до github>, не означает, что он должен синхронизироваться через github.
Я вот чего не понимаю.
Берем несколько примеров на гитхабе. Например:
import (
"log"
"net/http"
"github.com/AbdulwahabNour/photogallery/views" //<<< это часть проекта!
"github.com/gorilla/mux"
)
import (
"fmt"
"io"
"net/http"
"os"
"github.com/gildasch/upspin-photogallery/collection" //<<< это часть проекта!
"github.com/gildasch/upspin-photogallery/files" //<<< это часть проекта!
"github.com/gin-gonic/gin"
"upspin.io/client"
"upspin.io/config"
_ "upspin.io/transports"
)
При попытке сделать go build компилятор ругается и предлагает сделать go get недостающих пакетов, в том числе и тех, которые фактически являются частью проекта, и исходники которых уже скачаны из репозитория вместе с другим кодом проекта.
Что нужно сделать чтобы go build ругался только на то, что действительно внешнее? Например github.com/gorilla/mux — это действительно внешний модуль. Его нет в скачанных исходниках. А вот github.com/AbdulwahabNour/photogallery/views — это на самом деле просто папка "views" рядом с main.go
Это кривые проекты. Их авторы забыли добавить файл go.mod и некоторые другие. Напиши go mod init github.com/AbdulwahabNour/photogallery в каталоге с проектом, потом go get && go build.
В до-модульные времена (когда не изобрели go mod), все исходники на go должны были лежать в GOPATH, там строилась файловая система из путей к репозиториям и проектам. И нет никаких mod директорий — всё лежит в GOPATH — и свои и внешние зависимости.
ЕМНИП, начиная с версии 1.11, этот беспредел прекратился, и стало можно создавать проекты в любом месте — это и есть go modules.
Поэтому, когда будешь смотреть старые проекты могут выскакивать ошибки, упоминающие GOPATH, и т.д. (если в корне проекта нет go.mod и go.sum).
Тогда, если хочешь извратиться, то можешь настроить окружение для работы с GOPATH или попробовать сконвертировать их модули.
Сейчас GOPATH считается анахронизмом, но некоторые продолжают...
Здравствуйте, 00011011, Вы писали:
0>1. Прежде всего, мне попадается довольно много проектов, в которых наподключена куча всего с гитхаба. Это теперь так принято — доверять непойми чьему коду? Я понимаю в С++ существуют некие общепринятые библиотеки типа Буста, да и то во многих случаях их стараются избегать. А в Go другая философия? Есть ли хотя-бы какие-то "курируемые списки" хороших библиотек (желательно курируемые самими разработчиками языка)?
Ну вообще, конечно, принято смотреть, что включаешь. Смотреть, кто этим пакетом уже пользуется, кто автор, как развивается проект, не забросили ли его 10 лет назад.
Go гарантирует, что после того, как пакет подсосется первый раз, go.sum будет соответствующим образом обновлен (его надо хранить вместе с исходниками в репозитории), и в следующий раз будет использоваться ровно та же версия сторонних исходников.
0>2. Самое главное что непонятно — пути к собственным пакетам (т.е. тем, код которых включен в проект и написан тем же автором) тоже организованы через гитхаб. 0>В результате go, вместо того чтобы использовать локальные исходники, которые лежат тут же рядом, скачивает их с гитхаба, кладет в какую-то мутную папку вида c:/Users/<username>/go/pkg/mod, и компилирует оттуда.
Это у тебя твой собственный модуль как-то неправильно назван в go.mod. Если его имя совпадает с гитхабовским путем, то он будет браться из локальных исходников.
Ну и никто тебя не заставляет твой собственный код выкладывать на гитхаб и называть модуль гитхабовским путем. В этом есть смысл только, если ты естественным путем используешь гитхаб в разработке.
0>Мне вообще нравится концепция, когда исходники полностью самодостаточны и полностью компилируются на машине без интернета. Но здесь похоже все наоборот...
После первой загрузки все абсолютно самодостаточно.
Здравствуйте, vsb, Вы писали:
vsb>Это кривые проекты. Их авторы забыли добавить файл go.mod и некоторые другие. Напиши go mod init github.com/AbdulwahabNour/photogallery в каталоге с проектом, потом go get && go build.
Спасибо, вот теперь я понял — нужно в go.mod прописать название текущего проекта в том виде, как оно используется в секции import.
Т.е. с "github.com" и прочим.
>> Есть ли хотя-бы какие-то "курируемые списки" хороших библиотек (желательно курируемые самими разработчиками языка)?
vsb>Нет. Можешь смотреть на число звёздочек на гитхабе
Я мечтаю найти такой список, где на каждую определенную задачу рекомендуется пара-тройка проверенных, надежных библиотек, не больше. А то смотришь awesome go, и офигиваешь от разнообразия.
Здравствуйте, 00011011, Вы писали:
0>1. Прежде всего, мне попадается довольно много проектов, в которых наподключена куча всего с гитхаба. Это теперь так принято — доверять непойми чьему коду?
Сейчас принято у молодёжи х..к-х..к-продакшн. Да и у поклонников Истинного Слова Бизнеса тоже.
Общая идея: "Зачем думать? Есть же чейто код, который вроде работает."
Некоторые пытаются думать, но это единицы.
Здравствуйте, danilla, Вы писали:
D>Я мечтаю найти такой список, где на каждую определенную задачу рекомендуется пара-тройка проверенных, надежных библиотек, не больше. А то смотришь awesome go, и офигиваешь от разнообразия.
Скоро будет как с node modules. Числа об библиотеки складывать начнут
