Что за идиотизм с импортами в гуланге?

Лорчую, вон даже используют хипстер-старьё.

https://upload.wikimedia.org/wikipedia/commons/8/8f/Ken_Thompson_(sitting)_an...

Лорчую, вон даже используют хипстер-старьё.

Казалось бы, причем здесь Ричи и Томпсон, работающие на современной по тем временам технике, но анонимуса не проведешь.

решает Nix с его development environments.

я не уверен что это, но не удивлюсь если ты имеешь ввиду http://nixos.org/ :)

Скажем так — не самое худшее. ;)

When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.

Просто хипстеры так же известны использованием всякого устаревшего шатафа.

Скажем так — не самое худшее. ;)

из того, с чем мне приходилось сталкиваться, одно из самых худших. но сейчас вот go, и его инфраструктура, пытаются урвать первое место.

А если у тебя n проектов с библиотекой foo, для которых ты используешь «npm без -g», то сколько копий библиотеки foo у тебя будет?

Просто хипстеры так же известны использованием всякого устаревшего шатафа.

Причем тут Ричи, Томпсон и современный (тогда) PDP-11?

из того, с чем мне приходилось сталкиваться, одно из самых худших

А кто еще в тройке?

Основывался на словах Пайка.

На его словах лучше не основываться...

Ну он для меня более авторитетный источник, чем ты. Но пруфы выше авторитетов.

Ну он для меня более авторитетный источник

Авторитеты не нужны. Вся философия науки и результаты ее развития просто кричат об этом.

Пока я не обладаю всей полнотой информации, я могу использовать мнения эксперта для предварительной оценки.

А кто еще в тройке?

откуда взялась цифра «3»? по большому счету, подобные проблемы с организацией модулей, как в go и питоне, в основном если и существуют с другими языками/окружениями, то из-за идиотизма разработчиков конкретных проектов. а в этих двух они практически best practices.

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

откуда взялась цифра «3»?

После фразы «одно из самых» представляется длинный ряд плохих решений - меня бы устроило перечисление трех худших.

у меня есть претензии к организации модульности во многих окружениях, но там много субъективщины, и нет нерешаемых граблей.

давай будем считать, что номер 3 это CPAN (к счастью, в перле он на 100% опционален)

А что конкретно настолько плохо?

Проблема в том, что этой возможностью пользуются все

Это точно не проблема Go.

Его самого, https://nixos.org/wiki/Development_Environments

А что конкретно настолько плохо?

да весь тред же об этом, что тут еще добавлять?

Это точно не проблема Go.

Значит, когда одними штуками в языке стимулируют разработчиков делать что-то хорошо, то это — преимущество языка, а когда из-за других любую более-менее большую либу невозможно форкнуть без боли — то это не недостаток? Ога.

любую более-менее большую либу невозможно форкнуть без боли — то это не недостаток?

Осиль уже sed

Так, и что будет, если я форкну либу и накачу на нее свой патч?

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

Когда вот уже совсем никак не получается, пора читать инструкциюдокументацию.

Весь тред о go, я о pip спрашиваю.

Весь тред о go, я о pip спрашиваю.

а, ну pip сам по себе ничем не примечателен. он просто ставит пакеты туда, где питон может их найти. проблема же в том, что питон не может их искать в нормальном удобном месте, например в поддиректории modules твоего проекта, а только у себя в site-packages. а это, в свою очередь, приводит к костылям навроде virtualenv и ему подобным.

(пройдись вверх по ответам, я как раз про pyenv/virtualenv писал, а не про pip).

А если у тебя n проектов с библиотекой foo, для которых ты используешь «npm без -g», то сколько копий библиотеки foo у тебя будет?

гораздо более важный вопрос: будут ли копии библиотеки foo одинаковыми? проекты развиваются асинхронно, и зависимости в них обновляются по плану, а не пуллом с гитхаба для всех одновременно с криком leeroy jenkins!

В го тоже так можно, выше уже писали. Можно каждому проекту указывать свой GOPATH, можно использовать вендоринг зависимостей для конкретного проекта (и зависимостей зависимостей тоже).

выше уже писали.

но ты решил еще раз повторить? :)

а что если подменить репу на сетевом уровне и вместо нужного модуля говнокод будет импортировать vovan_wrapper где сверка ключей и прочее?

Ага, а безопасность кода - не проблема pure C.

Руки программиста - это одно. Типовые ошибки, которых не избежать при программировании на языке - это другое. Ошибки, заложенные в язык by design сознательно - это третье.

Что есть что в данном случае - каждый решает сам.

Нет, понятное дело, guns do not kill people (c), и выстрел в ногу делает в общем-то программист. Только когда тебе в пистолет пихают ядерную боеголовку, только потому что это «модно» - это не смешно

а я то думал что питон топ1 по этому(после джаваскрипта,он вне конкуренции)

это го обхожу стороной,язык детектор проекта-проект для тупой блондинки из офиса-100% на го(причем тупой современной блондинки,тупой по максимуму)

А вдруг ты пропустил? :)

Все срачи о го делятся на два типа: одни про импорты, другие про дженерики.

Я тут не понимал, почему они дженереки не запиливают. Но покодил тут серьёзно на джаве и утонул в болоте, затыканном @SafeVarargs и @SupressWarnings(«unchecked»). Уж лучше без них, чем так. Хуже только рефлексия

это го обхожу стороной,язык детектор проекта-проект для тупой блондинки из офиса-100% на го(причем тупой современной блондинки,тупой по максимуму)

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

когда одними штуками в языке стимулируют разработчиков

программист должен выбирать сам каким путем идти, язык возможности предоставляет.

большую либу невозможно форкнуть без боли

тут уже к психиатру. или 50 оттенков посмотри, говорят там как раз похожая история.

можно использовать вендоринг зависимостей для конкретного проекта

Я одного не пойму: как вы разруливаете версии библиотек, если вся информация о них - это ссылка на мастер? Вот ты сделал «вендоринг», и какие теперь версии зависимостей у тебя в проекте? Как синхронизироваться с основными репами? Должны же быть стабильные версии, экспериментальные и т.п. Может я чего не догоняю, но завязка на мастер это детский сад какой-то. Советы заводить новые репы при смене API вообще ахтунг.

guns do not kill people (c)

Вот с этого и надо было начать. Как как использовать инструмент - дело программера, а не самого инструмента.

https://github.com/golang/go/wiki/PackageManagementTools

Тысячи их. Можно указать ветку, коммиты, etc. Так же есть проксики с фиксированными релизами.

программист должен выбирать сам каким путем идти

Объясни, почему везде первым делом запиливают пакетный менеджер с мультиверсионностью, и только гоферы по-простецки импортят из мастера. Все не в ногу?

Ну это от организации разработки зависит. Я например с master мержрусь когда <feature-name>-ветка готова и протещщена. Таким образом в master у меня всегда самый «чистый» код.

На go не пишу, но картинные сцены я бы тут не устраивал. Это удобно (наверное). А если ты так зависишь от проекта - у тебя по-любому где-то есть бэкап его репы. В случае чего - можно и в свою репу утащить. А если следить за разработкой такой зависимости - параллельно разработке своего кода - то неожиданностей должно быть минимум. Плюс наверняка это каким-то образом стимулирует ... ээээ ... ну что-то хорошее наверняка стимулирует, лол.

Советы заводить новые репы при смене API вообще ахтунг.

Обоснуй.

Как по мне — несовметимое изменение API равнозначно новому проекту.

Изменишь ли ты циферку (и всем скажешь, что начиная с 3.1.4.1.5.9 оно больше несовместимо с тем, что было раньше) или дашь проекту новое имя — суть теже яйца, вид в профиль. Но при втором подходе хотя бы сразу ясно, что оно больше не совместимо.

Тред не читал. ТС уже создал issue на гитхабе или так и продолжает ныть?

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

А может первым делом лучше сделать, just works (as intended), и только потом заниматься мутью dependecy hell? ;)

как вы разруливаете версии библиотек

есть gopkg.in. А так, версия - это комит. Вот такой мрак, да.

Как синхронизироваться с основными репами?

Либо использовать один из менеджеров зависимостей, либо git pull.

Должны же быть стабильные версии, экспериментальные и т.п.

Есть пропозал про симвер. Сейчас в процессе обсуждения.

Советы заводить новые репы при смене API вообще ахтунг.

Как ни странно, это, в основном, работает :)

npm3 починил это.

Ты сам то понимаешь что несешь? Пинать автора либы, когда ты сделал критический хотфикс на релиз? Ты в продакшен давно писал то? Я бы посмотрел как ты отмазываешься что проебал все сроки из-за того, что автор либы второй день не отвечает тебе и вообще в свадебном путешествии.

А в чём разница с выбросом сторонней либой std::string в качестве исключения? Или исключения с переопределённым fillInStackTrace() в Java?

А если реально херню запилили и подгорает почти у всех - то разработчики вообще молодцы, да?

версия - это комит.
git pull
Есть пропозал про симвер.

Офигенно. Пожалуй стоит подождать лет 10, прежде чем тыкать палочкой в го.