People are complicated. You should expect to be misunderstood and to misunderstand others; when this inevitably occurs, resist the urge to be defensive or assign blame. Try not to take offense where no offense was intended. Give people the benefit of the doubt. Even if the intent was to provoke, do not rise to it. It is the responsibility of all parties to de-escalate conflict when it arises.
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