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

Форкаем проект github.com/vasa/project -> к себе github.com/peta/project Клоним локально, dep ensure Идем в dep и все локальные зависимости переделываем в dep на github.com/peta/project/*

я же правильно понял?

вернее даже "не трогаем локальные зависимости, правим в dep только когда необходимо что-то поправить внутри"

хотя в принципе даже main обычно лежит в /cmd/mainBinary/main.go что уже локальная зависимость

> Идем в dep и все локальные зависимости переделываем в dep на github.com/peta/project/* dep неасилятор детектед. в реальности в Gopkg.toml указывается github.com/peta/project, никакой /*

получается нам только source дописать к "старому"?

найти в депе constraint с github.com/vasa/project и подставить source = github.com/peta/project

создание костылей изза изначального неправильного дизайна импортов. Не разделение сущностей "что импортировать", "откуда импортировать". И мы имеем что имеем

найти в депе constraint с github.com/vasa/project и подставить source = github.com/peta/project

его там нет, скорее всего, его придется создать. но - да, одна секция.

создание костылей изза изначального неправильного дизайна импортов. Не разделение сущностей "что импортировать", "откуда импортировать". И мы имеем что имеем

придумайте лучше. условие - обойтись без центрального репозитория

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

аля C стайл

как хочу так и огранизовываю

и GOPATH туда-же

придумайте лучше. условие - обойтись без центрального репозитория

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

> как хочу так и огранизовываю ну и будет такой же превед, как в С/С++ мире.

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

стал быть - все уже хорошо?

стало быть что авторы придумаывает одно - а жизнь все расставляет по своим местам

какой сюрприз!

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

надо посмотреть как это сделано в С#, мне просто интересно как майкрософт подошел с правильным подходом

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

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

не знаю, я бы сделал какие то make файлы в которых можно прописывать было ассоциации, а в коде только импорты ИМЯ оставил

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

ну не правда же.

например?

не знаю, я бы сделал какие то make файлы в которых можно прописывать было ассоциации, а в коде только импорты ИМЯ оставил

привет автоматической подгрузке зависимостей.

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

еще раз - пример?

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

а чем плохи относительные зависимости и папочка vendor?

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

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

пример компилируемого языка с управлялкой зависимостями в экосистеме

а чем плохи относительные зависимости и папочка vendor?

тем, что непонятно, откуда качать вот эту конкретную зависимость, и которая из идентично именованных имеется в виду в настоящий момент. (CLASSPATH hell как он есть)

а чем плохи относительные зависимости и папочка vendor?

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

тем, что непонятно, откуда качать вот эту конкретную зависимость, и которая из идентично именованных имеется в виду в настоящий момент. (CLASSPATH hell как он есть)

ну для этого как раз есть отдельный файл...

один хрен мы уже на dep плотно сели

пример компилируемого языка с управлялкой зависимостями в экосистеме

тоесть вот имено компилируемого ? и имено в экосистеме? (а есть упрлавение зависиостями не в экосистеме)?

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

ну для этого как раз есть отдельный файл...

его что, руками составлять?!

руками

так надежнее

прописал в коде SUPERLIB, в файле прописал для нее репу

при форке - все хорошо

тоесть вот имено компилируемого ? и имено в экосистеме? (а есть упрлавение зависиостями не в экосистеме)?

да, да и да

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

руками

коллега @kirilldanshin был прав насчет мазохизма...

да, да и да

rust, cargo

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

они же ошибаюсься

не все сеньоры

руками

?‍♂️

rust, cargo

а расскажите пожалуйста, как сделано там

надо железное решение, которое нельзя испортить ? В моем случаи

а расскажите пожалуйста, как сделано там

да примерно так же как в каком нибудь maven

maven - это центральный репозиторий, я просил без него

https://medium.com/pantomath/go-tools-gitlab-how-to-do-continuous-integration-like-a-boss-941a3a9ad0b6

Removed msg from Vyacheslav Sitnikov. Reason: new user + external link

упс

коллега, сунте мне линк в личку, я перепощу

а оно вроде запостилось

maven - это центральный репозиторий, я просил без него

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

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

а оно вроде запостилось

DaySandBox admin, [24 Jun 2018 17:52:11]: Removed msg from Vyacheslav Sitnikov. Reason: new user + external link

я про ссылку на medium.com

ERROR: S client not available

плей не знаю, проверим

https://play.golang.org/p/HmnNoBf0p1z

не, тут человек с вопросом пришел, а робот его заколбасил

ааа

а расскажите пожалуйста, как сделано там

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

который пишется вручную?

очевидно да

коллега, сунте мне линк в личку, я перепощу

Vyacheslav Sitnikov, [24 Jun 2018 17:56:21]: Всем привет, помогите сохранить данные ( https://play.golang.org/p/7Z6hpt5jXf7 , закомментировано), ругается на cannot assign to struct field in map

который пишется вручную?

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

как будто в исходниках вы пишете пути не вручную

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

++

пути в сырках - зло

пути в сырках - зло

Похоже зло где-то в тебе бро

Vyacheslav Sitnikov, [24 Jun 2018 17:56:21]: Всем привет, помогите сохранить данные ( https://play.golang.org/p/7Z6hpt5jXf7 , закомментировано), ругается на cannot assign to struct field in map

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

пути в сырках - зло

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

Vyacheslav Sitnikov, [24 Jun 2018 17:56:21]: Всем привет, помогите сохранить данные ( https://play.golang.org/p/7Z6hpt5jXf7 , закомментировано), ругается на cannot assign to struct field in map

https://play.golang.org/p/5_2AR3O8Edq

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

Ну я пошёл по второму пути, но мало ли, может я что-то делал не так :) Спасибо

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

По опыту подход Го лучше на много. Особенно после ужасов maven и nuget

ну этот который из ржавчины от них ни чем не отличается

очевидно да

очевидно, примеров нет. спасибо.

очевидно, примеров нет. спасибо.

очевидно вы не хотели примеров.

все еще хочу. но эти примеры - не соответствуют условию

если есть еще - публикуйте, пожалуйста

пример компилируемого языка с управлялкой зависимостями в экосистеме

вот этому условию ?

я не зря уточнил условие

там было условие еще, "без центрального репозитория"

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

ну вобщем занимайтесь демагогией

коллега, почитайте нашу переписку сначала

я свое условие про центральную репу выдвинул сразу