должны

должны

нет

ну ок

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

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

мы про чужой опыт же, а не про мои знания

успели забыть?

А пытаетесь завалить вопросами ч тобы потом сказать - "ВОТ! ВЫ ЖЕ ДАЖЕ НЕ ПОИНМАЕТЕ КАК ЭТО РАБОТАЕТ! Я ВАМ НИЧЕГО НЕ СКАЖУ" Выглядит печально.

коллега, переходите к конструктиву, или перестаньте

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

к такому конструктиву?

А пытаетесь завалить вопросами ч тобы потом сказать - "ВОТ! ВЫ ЖЕ ДАЖЕ НЕ ПОИНМАЕТЕ КАК ЭТО РАБОТАЕТ! Я ВАМ НИЧЕГО НЕ СКАЖУ" Выглядит печально.

Keep calm and use gb

к такому конструктиву?

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

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

спасибо

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

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

Почти не надо, на самом деле

Почти не надо, на самом деле

скажем так, если внутренние пакеты не по семверу или внутренних пакетов вообще нет — то не надо

если у вас есть какая-то внутренняя инфраструктура пакетов с зависимостями вежду ними и версиями — то правка gopkg.toml превращается в рутину

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

Разве? У меня все из мастера внутреннее. И только для экспериментов иногда я переключаю ветки

Разве? У меня все из мастера внутреннее. И только для экспериментов иногда я переключаю ветки

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

хотя конечно я скорее всего слишком сильно проецирую свой опыт

Вот да :)

народ, а какая максимальная длинна string?

в гошечки

Это в гугл

Кто же это запоминает

народ, а какая максимальная длинна string?

MaxInt64 в байтах, но это не точно

Вот да :)

всё таки нет ?

эх

Да ну?

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

Обратную совместимость соблюдать?

ну простейший пример — проект A импортирует библиоотеку B и оба находятся в активной разработке

Обратную совместимость соблюдать?

это не всегда возможно к сожалению

особенно на ранних этапах

а так хотелось бы, кто бы спорил

Чего-то я не понимаю

Вот у нас проект

Вот мы закоммитили вендор

Все у нас хорошо, так?

Вот нам понадобился новый функционал от второго проекта

если есть только этот проект — то всё прекрасно

Мы такие dep ensure -update, поправили, что сломалось, и опять закоммитили вендор

Где тут ручная правка gopkg.toml?

стоп, закомитили вендор? O_o

Вот я так и думал, что тут корень

Да, вендор надо коммитить

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

и репозиторий разрастается

Где тут ручная правка gopkg.toml?

это пока не выставлен минорный диапазон версий

как надо делать по-нормальному (а лучше вообще на фиксированную версию)

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

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

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

он должен подтянуться вручную на этапе сборки же

из dep

как надо делать по-нормальному (а лучше вообще на фиксированную версию)

На этапе бурной разработки?!

На этапе бурной разработки?!

именно на ней

Зачем?

потом когда уже нет ломающих изменений — то особо уже и не страшно

Gopkg.lock не достаточно?

Зачем?

потому что именно на ранних этапах всё регулярно ломают и хочется уметь обновлять часть зависимостей, точно зная что ничего при этом не сломается

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

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

Это вы .gitattributes не умеете готовить

и репозиторий разрастается

А не пофиг?

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

Почему gopkg.lock не работает?

Почему gopkg.lock не работает?

да он работает просто когда делаешь мажорное обновление зависимости, то это по-хорошему надо делать выставляя новую версию в gopkg/toml "~v1.0.0" -> "~v2.0.0"

ERROR: S client not available

А! Ну да, если есть требования по версии - их придется указывать :) Только откуда взяться требованиям по версии на этапе бурной разработки?

А! Ну да, если есть требования по версии - их придется указывать :) Только откуда взяться требованиям по версии на этапе бурной разработки?

А это чисто для внутреннего пользования

Может, просто не надо слишком рано начинать фиксировать версии? :)

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

Может, просто не надо слишком рано начинать фиксировать версии? :)

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

Имхо

Разве?

От тегов еще туда-сюда, но от версий?

Нет же плана поддерживать несколько ранних версий, так?

Значит - в рельности есть только последняя, и к ней надо все тянуть

Нет же плана поддерживать несколько ранних версий, так?

Одна версия для прода, другая девелоперская как минимум

От тегов еще туда-сюда, но от версий?

Это по сути и есть теги, просто чуть более умные

Я на прошлой неделе именно это делал... Делай сам. Нет готовых либ, которые как-то облегчат твою жизнь.

Как это нет?! Есть! Я сейчас кину ссыль

А, она не на го

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

нужна простенькая либа чтобы переменные окружения и флаги и дефолтовые значения попроще цеплять (т.е нужен приоритет дефаулт->окружение->флаги прозрачно и просто)

Viper?

Viper?

> Простенькая

Или как там его...

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

Ну, мне нечего сказать кроме того, что это мягко говоря не так

И то и то живёт слишком бурной жизнью

Viper?

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

нужна простенькая либа чтобы переменные окружения и флаги и дефолтовые значения попроще цеплять (т.е нужен приоритет дефаулт->окружение->флаги прозрачно и просто)

sflags Очень рекомендую

Ну, мне нечего сказать кроме того, что это мягко говоря не так

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

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

Потому что уже есть клиенты на первой версии, и требования "заказчика" меняются со временем, переодически приводя к нарушению обратной совместимости

sflags Очень рекомендую

все время забываю про него :(

все время забываю про него :(

Я сейчас потихоньку мигрируют на него И, блин, это прекрасно

Потому что уже есть клиенты на первой версии, и требования "заказчика" меняются со временем, переодически приводя к нарушению обратной совместимости

это, все же, не типичная ситуация.

Я сейчас потихоньку мигрируют на него И, блин, это прекрасно

а у меня у самого везде flag, а не у меня везде viper

sflags Очень рекомендую

для меня это пока ненужная абстракция в данном конкретном проекте

это, все же, не типичная ситуация.

Я повторюсь, ни в коем случае не говорю что наш подход — это единственно верный и идеальный путь для каждого

для меня это пока ненужная абстракция в данном конкретном проекте

Плюс как раз в том, что это не вносит абстракций, а просто уменьшает бойлерплейт