если корпоративный стеш мигранет, то да

Кстати о троллинге, который не троллинг. Расскажите, плз, или дайте ссылку где прочитать, на предмет извращенной логики создателей в плане проектирования путей импортов. Особенно интересует почему я должен в своем коде хардкодить полные пути к либам? И как быть, если либы лежат в корпоративном гите и адрес гита периодически меняется? (не спрашивайте почему, оптимизация...)

Ну чтобы постоянно не менять адрес/имя корпоративного гита - проще править hosts, чем исходники

если так то git clone addr <name project> import <name project>/mylib/lib1

а не домен/mylib

Ну чтобы постоянно не менять адрес/имя корпоративного гита - проще править hosts, чем исходники

это костыль. Адовый!

Ну а импорт в go уже сделан тут хоть обфантазируйся

а не домен/mylib

go get как делать?

если корпоративная либа, но не входит в аппликуху то чем она не сторонняя ?

где тебе нужен го кет?

можно поднять корпоративный аналог gopkg.in если там постоянно что то куда то мигрирует

гет

это костыль. Адовый!

Это не костыль - а единственно верное решение

Ну а импорт в go уже сделан тут хоть обфантазируйся

так это понятно, что уже не провернешь этот фарш назад. Вопрос один - зачем?

Это не костыль - а единственно верное решение

Ты всем разрабам будешь это рекомендовать? В доке спецом описывать?

тру вэй - проблема с импортами с больной головы на здоровую перекладывается

так это понятно, что уже не провернешь этот фарш назад. Вопрос один - зачем?

Ну это вопрос к создателем языка, МБ это связано с тем, что го родился в plan9

Ты всем разрабам будешь это рекомендовать? В доке спецом описывать?

Ну если админы так косячат, то да.

где тебе нужен го кет?

в dep например. Хочу диреторию vendor создать с либами, а они все на старый стеш показывают. Все либы рефачить - вообще не удовольствие.

Ну если админы так косячат, то да.

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

стеш?

что стеш?

это атлассиановское поделие

по-факту git

ясно

загуглил

аналог ghe, только дешевле

в glide можно указать адрес для либ

в Деп наверно тоже можно

т.е. испортируешь как Github.com/lib а на самом деле с mydomain.com/lib

в dep например. Хочу диреторию vendor создать с либами, а они все на старый стеш показывают. Все либы рефачить - вообще не удовольствие.

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

имя моей либы - mylib. Даже если ее обозвать полным путем, зачем этот путь хардкодить в сырцах, а не вынести ее полный путь в отдельный конфиг, как это сделано в других языках?

повторю вопрос - какая проблема решается этим извращением?

вот я и пытаюсь понять эту логику и какие проблемы решаются с ее помощью

для начала прийми что github.com/user/project/sub/mylib это importPath опосредовано имеющее отношение к packagename и смерись с этим, конечно симлинки тебе могут помощь , но создадут доп. проблемы с поддержкой

почему именно так, а не как в том-же богомерзком npm?

имя моей либы - mylib. Даже если ее обозвать полным путем, зачем этот путь хардкодить в сырцах, а не вынести ее полный путь в отдельный конфиг, как это сделано в других языках?

нет, так называется конечный пакет.

а чем тебе npm не нравится

повторю вопрос - какая проблема решается этим извращением?

у тебя mylib и у меня mylib как различать третьему кому они обе нужны ?

имя моей либы - mylib. Даже если ее обозвать полным путем, зачем этот путь хардкодить в сырцах, а не вынести ее полный путь в отдельный конфиг, как это сделано в других языках?

в php такого нет, в js такого нет, в c такого нет, в java такого нет. везде имопртируется полное имя пакета

различать конечго можно, но как импортировать

в php такого нет, в js такого нет, в c такого нет, в java такого нет. везде имопртируется полное имя пакета

шта? import java.util.Date вполне себе без указания репы работает

различать конечго можно, но как импортировать

как обычно. ... as mylib2

шта? import java.util.Date вполне себе без указания репы работает

а что по твоему java.util.Date? еще раз, забудь про пути. это название пакета

Прописывать полные пути импортов - это не проблема. Проблема - это наличие двух пакетов с одинаковыми именами, которую решают полные пути

а что по твоему java.util.Date? еще раз, забудь про пути. это название пакета

да, почему в Го также не сделали?

Прописывать полные пути импортов - это не проблема. Проблема - это наличие двух пакетов с одинаковыми именами, которую решают полные пути

ок, я понял, но хардкодить их зачем? Почему в конфиг dependency-manager'а не вынести?

В го сделали init

ок, я понял, но хардкодить их зачем? Почему в конфиг dependency-manager'а не вынести?

Как это должно выглядеть?

ок, я понял, но хардкодить их зачем? Почему в конфиг dependency-manager'а не вынести?

так ты можешь это делать

!!!!!! я не читал доку по dep!!!!! но вангую, что можно так [[constraint]] name = "mylib" source = "https://mydomain.com/mylib.git" branch = "parse-constraints-with-dash-in-pre"

да, почему в Го также не сделали?

сделали. я понял - тебя смущает встроенная поддержка github.com итд и соответственно наличие имени домена в импорте? так сделано, потому что в языке не было пакетных менеджеров и единого реестра пакетов. зато ты можешь всосать в свой проект любой репо

Как это должно выглядеть?

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

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

но в го нет никакого конфига

дальше запускаешь dep-manager и он тебе их в локальную папочку складывает

дальше запускаешь dep-manager и он тебе их в локальную папочку складывает

dep не является частью языка

где гошшечка их видит и использует _БЕЗ_ абсолютных путей

ок, я понял, но хардкодить их зачем? Почему в конфиг dependency-manager'а не вынести?

прийми что это и есть имя пакета и тебе станет проще, а твой mylib типа области видимости который меняется на что угодно

dep не является частью языка

и? это мешает сделать человеческие импорты?

где гошшечка их видит и использует _БЕЗ_ абсолютных путей

го все видит в относительных

и? это мешает сделать человеческие импорты?

и генерики

и кучу всего еще

как обычно. ... as mylib2

это имено различать, а не импортировать

и? это мешает сделать человеческие импорты?

они человеческие. просто в твоем кейсе, когда меняется репозиторий, он не подходит.

ладно.. я понял, что эту проблему можно решить кастомным GOPATH и своим dep с блекждеком и отсутствием vendor.

спасибо за то, что навели на эту мысль

ладно.. я понял, что эту проблему можно решить кастомным GOPATH и своим dep с блекждеком и отсутствием vendor.

это не проблема

ERROR: S client not available

не пользуйтесь, я вас не заставляю

я решаю СВОЮ проблему

а не вашу

проще сделать аналог bower и жить спокойно без этих геморов с импортами

проще сделать аналог bower и жить спокойно без этих геморов с импортами

ты можешь рамках issue на гитхабе собрать статистику сталкивается ли кто-то с этой проблемой. тогда узнаешь проще ли или всех устраивает встроенная поддержка vcs-репозиториев

2 million lemmings can't be wrong (c)

переходите на раст

Дельная мысль

не... я там был, там свои тараканы

не... я там был, там свои тараканы

зато там пакетный менеджер нормальный

и не нужно импортить по путям

2 million lemmings can't be wrong (c)

нет, конечно прав хомяк с рандомно меняющимся репозиторием

use MyLib::*

слушай, мне нравится го, причем очень. Но импорты меня выбешивают. Решив эту проблему я буду иметь отличный инструмент для решения 99% своих задач.

слушай, мне нравится го, причем очень. Но импорты меня выбешивают. Решив эту проблему я буду иметь отличный инструмент для решения 99% своих задач.

либо шашечки, либо ехать

ваще не из этой оперы

оно едет и сейчас отлично, просто выглядит как кусок гуано

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

жизнь, жизнь заставляет.

а не прихоть

да и меня бесят полные пути с 8 слешами в шапке каждого файла

неаккуратненько (с)

name это путь импорта?

нет, это название пакета

что в данном случае одно и тоже

можно указать название как project2, и импортить его как project2

слушай, мне нравится го, причем очень. Но импорты меня выбешивают. Решив эту проблему я буду иметь отличный инструмент для решения 99% своих задач.

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

можно указать название как project2, и импортить его как project2

что-то не получается (

The following issues were found in Gopkg.toml: ✗ "tablewriter" is not a valid import path