Та мне как-бэ нет желания на них время тратить, когда все дружно решили облить меня дерьмом.
Решения такого не было.
Плохо помню ситуацию, но вроде ему тоже объясняли, что он не прав. Просто с примерами, а не с матом.
Я не буду объяснять почему регидному козлу, которого всё устраивает в жизни, сложно объяснить что у кого-то может быть по другому.
Пустая трата времени: он будет искать коллективы поощряющие его безответственность и лень - просто полный "Ship It" и бизнес-план Подштанниковых Гномов из South Park'a. Но это не значит что все делают точно так же.
Та мне как-бэ нет желания на них время тратить, когда все дружно решили облить меня дерьмом.
Мне минимум 4 тела сказали что я вообще дурак, ничего не знаю и выпендриваюсь - должен всем всё Доказывать!
Доказывать нужно только тем... у кого есть блок восприятия и они не способны даже предположить что их собеседник может быть в чём-то прав - это просто слишком болезненно. Тут уже можно начинать разглагольствовать о личных кризисах и отсутствии самореализации... я не собираюсь быть компенсацией чей-то посредственности.
Это ведь ты написал письмо с просьбой добавить тебя?
Меня пригласили в украинское Golang комьюнити по инвайту с канала #ukraine в слаке golang'a.
Я сегодня написал инвайт в 4gophers.ru. Если это одно и тоже - ну что же... очень жаль.
Давать сдачи, да посильнее, не надо.
Просто надо разобраться кто тут троль, и кто не может сразу ответить на вопрос "Ты бенчмарки гоняешь ?"...
Прежде чем окажется после 30 минут переписки и "НЕТ! ДАВАЙ ОБСУДИМ!" - "А зачем мне бэнчмарки на FS гонять - я же не дурак".
Я не защищаюсь...
Просто банить и покрывать: "Ну вы все поняли кто он такой".
НУ ок... ПОСРЕДСТВЕННОСТЬ.
Думал вы будете чуток выше этого.
Меня пригласили в украинское Golang комьюнити по инвайту с канала #ukraine в слаке golang’a.
Я сегодня написал инвайт в 4gophers.ru. Если это одно и тоже - ну что же… очень жаль.
Это не одно и тоже. Ничего не знаю про первое (первый раз слышу :) ), но в golang-ru канала #ukraine нет, есть #meetup-ukraine.
Просто банить
Банили по формальному признаку – за мат
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.
@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
?https://{servername}/projects/{project_name}/repos/{repo_name}/browse/{folder_name}
Здесь {folder_name}
это наша папка service
. И что, мне структуру пакетов завязывать вот на эту жесть с browse и прочим хламом?go get
. Значит мне все эти завязки на репозитории не нужны и я могу просто использовать относительные пути?$GOPATH/src/your_folder
git clone
в $GOPATH/src/
+ go get
без аргументов в папке с main.go должно быть достаточно. Также для менеджмента зависимостями есть много сторонних библиотек которые работают по описанному тобой принципу с отдельным $GOPATH, например govendor.import (
"./service"
)
то есть лучше:"myfolder/service"
под гопаз$GOPATH/src/
.$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 запрещён циклический импорт - ты не можешь в пакете А заимпортить пакет Б, а в пакете Б заимпортить пакет А.