https://github.com/hagen1778/fasthttploader от верты
https://github.com/codesenberg/bombardier от яндыкса
Чаще всего использую
https://github.com/tsenart/vegeta
@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.
- Допустим я только начинаю разработку и у меня еще нет репы. При этом я уже хочу, чтобы мои зависимости нормально резолвились. Выходит, мне надо либо копировать сорцы в глобальный
$GOPATH, имитируя таким образом go get, либо задавать$GOPATHссылающийся на директорию проекта, при этом проект теперь обязан находиться в директрииsrc? - Если завтра кто-то захочет собрать у себя проект, ему не только git clone надо сделать, но и вызвать go get (на каждый импорт?), либо прописать $GOPATH к только что склонированному проекту?
- Как задавать импорт, если это не гитхаб репозиторий, а, скажем, битбакет? На примере существующего репозитория я вижу такой URL-темплейт:
Здесьhttps://{servername}/projects/{project_name}/repos/{repo_name}/browse/{folder_name}{folder_name}это наша папкаservice. И что, мне структуру пакетов завязывать вот на эту жесть с browse и прочим хламом? - Если завтра проект переедет с битбакета на гитхаб, мне надо будет обновить все импорты?
- Я не разработчик библиотеки и не ожидаю, что кто-то будет вытягивать мой код с помощью
go get. Значит мне все эти завязки на репозитории не нужны и я могу просто использовать относительные пути?
- Тебе ничего не мешает просто иметь папку под $GOPATH без указания ремоут пути. Тоесть
$GOPATH/src/your_folder
Но сорц код лучше держать под одним $GOPATH. git cloneв$GOPATH/src/+go getбез аргументов в папке с main.go должно быть достаточно. Также для менеджмента зависимостями есть много сторонних библиотек которые работают по описанному тобой принципу с отдельным $GOPATH, например govendor.- см 1.
- Завязки на репы можно скипнуть но так лучше не делать:
то есть лучше:import ( "./service" )
под гопаз"myfolder/service"
Ну есть много инфы об этом. Это рекомендация от гугл.
https://stackoverflow.com/questions/38517593/relative-imports-in-golang
https://groups.google.com/forum/#!topic/golang-nuts/7t_KN1LdOSA
https://stackoverflow.com/questions/10687627/relative-import-from-parent-directory
$GOPATH/src/.У нас моно репозиторий. Куча модулей на разных языках, преимущественно java. Если я это все склонирую, то мне даже тяжело представить что может произойти. Долбаться со sparse checkout не хотелось бы.
Опять же, вести всю разработку в
$GOPATH/src/ как-то странно. Он у меня и источник зависимостей и рабочий проект одновременно. А если этого не делать, то мне каждый репозиторий надо клонировать по два раза: в рабочую директорию и в $GOPATH/src/. При этом надо не забывать последний поддерживать в актуальном состоянии.Я понимаю, что проблема заезженная, поэтому всем лень отвечать, но хоть ссылкой в меня киньте, где это нормально объяснено.
@xCASx
1 Допустим я только начинаю разработку и у меня еще нет репы.
Ты просто делаешь mkdir -p $GOPATH/src/github.com/xCASx/dummyproj идешь туда и стартуешь новый проект
ча модулей на разных языках, преимущественно java. Если я это все склонирую, то мне даже тяжело представить что может произойти.
Есть vendor и ты можешь использовать нормальный пакетный менеджер, я использую glide
Опять же, вести всю разработку в $GOPATH/src/ как-то странно.
Общепринятая практика, просто надо привыкнуть - погоды не делает.
Пускай $GOPATH/src/ и является твоей рабочей папкой...
Долбаться со sparse checkout не хотелось бы.
Тут такого нету - никто не клонит один проект в два места.
Если ты хочешь отказаться от $GOPATH/src то тебе придётся клонить твой проект submodule'ом в vendor и там его ещё и .gitignore'ить %)
Что будет ещё более костыльно и неприятно.
Если завтра кто-то захочет собрать у себя проект
Пускай используют пакетный менеджер
Здесь {folder_name} это наша папка service. И что, мне структуру пакетов завязывать вот на эту жесть с browse и прочим хламом?
У гита были alias'ы вроде как... а структура действительно вырвиглазная.
Если завтра проект переедет с битбакета на гитхаб, мне надо будет обновить все импорты?
Да. Но ты можешь заюзать православный find . | sed -i '' ...
Значит мне все эти завязки на репозитории не нужны и я могу просто использовать относительные пути?
Нужны так как в golang'e запрещён циклический импорт - ты не можешь в пакете А заимпортить пакет Б, а в пакете Б заимпортить пакет А.
Ребят, подскажите, как правильно в Го сделать словарь с мьютексами, что-то типо такого
mutexes = map[string]*sync.Mutex
mutexes[key].Lock()
defer mutexes[key].Unlock()Есть поток ключей, который слушают горутины, и нужно чтобы одинаковые ключи обрабатывались только одной горутиной. Т.е. если пришло 2 одинаковых ключа подряд, их взяли две разные горутины, но вторая ждет мьютекса.
_, игнорируются утилитой go
_test.go