Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 21 2016 13:31
    @listochkin banned @MayyaLitvina
  • Mar 15 2015 01:09
    User @mr-mig banned @putin-hero from this room
  • Mar 15 2015 01:08
    User @mr-mig banned @stepan-bendera from this room
skliarovartem
@skliarovartem
есть слайс, нужно залить в бд. неужели нужно каждый айтем отдельно заливать? 0___о
Yehor Nazarkin
@nimnull
в v2 можно, кроме того, есть Bulk операции
но его нужно распаковать
Maxim Kolesnikov
@xCASx

Привет! Помогите разобраться с концепцией GOPATH.
 Допустим, структура проекта такова:


.
├ main.go
└ service
  └ myservice.go

Какие есть пути, чтобы в main.go импортировать myservice.go?

Anton Lempiy
@lempiy

@xCASx из примера golang.org https://golang.org/doc/code.html
допустим указанная выше структура лежит под $GOPATH/src/github.com/user/mymain тогда импорт service в main.go будет следующим:

import (
    "github.com/user/mymain/service"
)

Конечно же это сработает при условии, что имя пакета в myservice.go будет - service.
Смисл в том, что при такой структуре локальный путь к пакету дублирует remote url что дает возможность с легкостью применить go get на каждый из пакетов.
Есть возможность использовать относительные пути к пакетам не под gopath, но это считается bad practice.

Maxim Kolesnikov
@xCASx
@lempiy спасибо за пояснение. Эта часть мне ясна. Чего я не могу понять:
  1. Допустим я только начинаю разработку и у меня еще нет репы. При этом я уже хочу, чтобы мои зависимости нормально резолвились. Выходит, мне надо либо копировать сорцы в глобальный $GOPATH, имитируя таким образом go get, либо задавать $GOPATH ссылающийся на директорию проекта, при этом проект теперь обязан находиться в директрии src?
  2. Если завтра кто-то захочет собрать у себя проект, ему не только git clone надо сделать, но и вызвать go get (на каждый импорт?), либо прописать $GOPATH к только что склонированному проекту?
  3. Как задавать импорт, если это не гитхаб репозиторий, а, скажем, битбакет? На примере существующего репозитория я вижу такой URL-темплейт:
    https://{servername}/projects/{project_name}/repos/{repo_name}/browse/{folder_name}
    Здесь {folder_name} это наша папка service. И что, мне структуру пакетов завязывать вот на эту жесть с browse и прочим хламом?
  4. Если завтра проект переедет с битбакета на гитхаб, мне надо будет обновить все импорты?
  5. Я не разработчик библиотеки и не ожидаю, что кто-то будет вытягивать мой код с помощью go get. Значит мне все эти завязки на репозитории не нужны и я могу просто использовать относительные пути?
Сорян за обилие вопросов, но пока у меня эта концепция в голове не очень помещается.
Anton Lempiy
@lempiy
Я сам не особо опытный в Go, но тебе никто не отвечал, а потому попробовал ответить. По поводу твоих вопросов: (Надеюсь, тебе здесь дадут более точные/правильные ответы)
  1. Тебе ничего не мешает просто иметь папку под $GOPATH без указания ремоут пути. Тоесть
    $GOPATH/src/your_folder
    Но сорц код лучше держать под одним $GOPATH.
  2. git clone в $GOPATH/src/ + go get без аргументов в папке с main.go должно быть достаточно. Также для менеджмента зависимостями есть много сторонних библиотек которые работают по описанному тобой принципу с отдельным $GOPATH, например govendor.
  3. см 1.
  4. Завязки на репы можно скипнуть но так лучше не делать:
    import (
    "./service"
    )
    то есть лучше:
    "myfolder/service"
    под гопаз
@xCASx ^
Maxim Kolesnikov
@xCASx
@lempiy так а в чем проблема с относительными путями?
Maxim Kolesnikov
@xCASx
@lempiy меня просто очень смущает второй пункт. То, что мне надо делать git clone в $GOPATH/src/.
У нас моно репозиторий. Куча модулей на разных языках, преимущественно java. Если я это все склонирую, то мне даже тяжело представить что может произойти. Долбаться со sparse checkout не хотелось бы.
Опять же, вести всю разработку в $GOPATH/src/ как-то странно. Он у меня и источник зависимостей и рабочий проект одновременно. А если этого не делать, то мне каждый репозиторий надо клонировать по два раза: в рабочую директорию и в $GOPATH/src/. При этом надо не забывать последний поддерживать в актуальном состоянии.
Я понимаю, что проблема заезженная, поэтому всем лень отвечать, но хоть ссылкой в меня киньте, где это нормально объяснено.
Yuriy Yarosh
@yuriy-yarosh

@xCASx

1 Допустим я только начинаю разработку и у меня еще нет репы.

Ты просто делаешь mkdir -p $GOPATH/src/github.com/xCASx/dummyproj идешь туда и стартуешь новый проект

ча модулей на разных языках, преимущественно java. Если я это все склонирую, то мне даже тяжело представить что может произойти.

Есть vendor и ты можешь использовать нормальный пакетный менеджер, я использую glide

Опять же, вести всю разработку в $GOPATH/src/ как-то странно.

Общепринятая практика, просто надо привыкнуть - погоды не делает.
Пускай $GOPATH/src/ и является твоей рабочей папкой...

Долбаться со sparse checkout не хотелось бы.

Тут такого нету - никто не клонит один проект в два места.

Если ты хочешь отказаться от $GOPATH/src то тебе придётся клонить твой проект submodule'ом в vendor и там его ещё и .gitignore'ить %)
Что будет ещё более костыльно и неприятно.

Anton Lempiy
@lempiy
@yuriy-yarosh :+1:
Yuriy Yarosh
@yuriy-yarosh

Если завтра кто-то захочет собрать у себя проект

Пускай используют пакетный менеджер

Здесь {folder_name} это наша папка service. И что, мне структуру пакетов завязывать вот на эту жесть с browse и прочим хламом?

У гита были alias'ы вроде как... а структура действительно вырвиглазная.

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

Да. Но ты можешь заюзать православный find . | sed -i '' ...

Значит мне все эти завязки на репозитории не нужны и я могу просто использовать относительные пути?

Нужны так как в golang'e запрещён циклический импорт - ты не можешь в пакете А заимпортить пакет Б, а в пакете Б заимпортить пакет А.

Maxim Kolesnikov
@xCASx
@yuriy-yarosh спасибо! Просто как-то много церемоний получается. Мне надо проект из трех файлов собрать, а я уже два дня разобраться не могу как же оно должно быть правильно.
Yuriy Yarosh
@yuriy-yarosh
Можешь писать мне сюды https://discord.gg/8dFGXrx или прямо в скайп %)
Помогу по возможности ...
Maxim Kolesnikov
@xCASx
@yuriy-yarosh благодарю ;)
Maxim Kolesnikov
@xCASx
Подскажите, в го есть поддержка интерсепторов, или мне надо самому написать обертку и заворачивать в нее каждый хендлер?
TarasZak
@taras-zak

Ребят, подскажите, как правильно в Го сделать словарь с мьютексами, что-то типо такого

mutexes = map[string]*sync.Mutex 
mutexes[key].Lock()

defer mutexes[key].Unlock()

Есть поток ключей, который слушают горутины, и нужно чтобы одинаковые ключи обрабатывались только одной горутиной. Т.е. если пришло 2 одинаковых ключа подряд, их взяли две разные горутины, но вторая ждет мьютекса.

Yuriy Yarosh
@yuriy-yarosh
@taras-zak тебе нужен RWLock а не мьютексы ...
@xCASx нету, если очень нужно - лучше запилить на горутинах.
... с горутинами напрягает отсутствие backpressure control :(
Maxim Kolesnikov
@xCASx
@yuriy-yarosh ну я наклепал в итоге обертку и в нее заворачиваю. Авторизацию ж надо как-то делать...
Yuriy Yarosh
@yuriy-yarosh
Авторизация дело тонкое
Я вот на React Kiev готовлю доклад про релешку ... там очень оригинально авторизация выполняется
Maxim Kolesnikov
@xCASx
@yuriy-yarosh мне не надо оригинально. Мне надо просто и чтоб работало :D
TuxUbuntu
@TuxUbuntu
привет, ребята, подскажите, что я делаю не так:
запускаю в папке с исходниками go test _test_Source.goа мне выдаёт can't load package: package main: no buildable Go source files in /go/src/mirror
Alexey Palazhchenko
@AlekSi
не надо так файл называть
Файлы, начинающиеся с _, игнорируются утилитой go
Файл с тестом должен заканчиваться на _test.go
И при этом хотя бы один файл без тестов должен быть
Maxim Kolesnikov
@xCASx

А что за проблемы у Go c PKCS12 хранилищами? Если я импортирую хранилище с ключем и сертификатом - все ок. Но если в хранилище только сертификат (аналог truststore в Java), то я получаю ошибку:

pkcs12: expected exactly two items in the authenticated safe

Yuriy Yarosh
@yuriy-yarosh

А что за проблемы у Go c PKCS12 хранилищами?

Просто захардкодили, типа ключ и серт - и ниипёт.
Обычно стоит глянуть исходники в таких случаях.

Maxim Kolesnikov
@xCASx
@yuriy-yarosh да там и из сообщения ошибки все понятно, в принципе. Непонятно почему так захардкодили.
Anton Lempiy
@lempiy
Вопрос по кросс компиляции. Нужно время от времени компилировать с linux amd64 на windows 386. Проблема в том, что есть зависимость от пакетов работающих на C+GO. В частности https://github.com/mattn/go-sqlite3 . Понятное дело нужен какой то кросс компайлер і для С/С++ . Пробовал mingw-w64 (CC=mingw-w64), но go build как будто не реагирует на задание кастомного C-компилятора. У кого то была такая проблема/необходимость?
только что попробовал скомпилировать с windows amd64 на windows 386 используя mingw-w64 - скомпилировалось. Но хотелось бы компилировать с под linux.
Yuriy Yarosh
@yuriy-yarosh
@lempiy golang/go#11058
Eugene
@jdevelop
@lempiy я сделал через docker
как раз делает все правильно
Anton Lempiy
@lempiy
@jdevelop Oo :+1: норм идея
Eugene
@jdevelop
да, там только надо будет подкрутить образ чтобы поставить го
Anton Lempiy
@lempiy
Тоесть, создать свой докерфайл на основе их имиджа, правильно?
Eugene
@jdevelop
да
там уже поставлены все нужные MingW и прочий тулчейн с правильными бинариками для нужной линковки, все что нужно сделать - просто запустить имедж и запустить сборку в нем
Anton Lempiy
@lempiy
Ок, спс!
Oleksandr
@pifagor87
Привіт. Хтось стикався з - jackc/pgx#378
Yuriy Yarosh
@yuriy-yarosh
Просто Numeric с Integer'a не расспаковывается, это надо ковырять go-pg на сколько помню.
Oleksandr
@pifagor87
там не go-pg а pgx
Eugene
@jdevelop
никто Go в ардуину не пихал?