Comments 48
Извиняюсь за оффтоп, я не писал на Go (пока), но судя по документации, стандартный менеджер зависимостей скачивает исходники зависимостей из репозиториев, можно ли при этом указать версию зависимости или всегда скачивается последняя?
-2
Да, всегда скачивается последняя.
Для менеджмента версий зависимостей используют или отдельные менеджеры зависимостей/версий (godeps/gpm/etc) или просто копируют third-party библиотеки в свою кодовую базу (а дальше или отдельный GOPATH или решения вроде vend).
Вот еще в FAQ: golang.org/doc/faq#get_version
Для менеджмента версий зависимостей используют или отдельные менеджеры зависимостей/версий (godeps/gpm/etc) или просто копируют third-party библиотеки в свою кодовую базу (а дальше или отдельный GOPATH или решения вроде vend).
Вот еще в FAQ: golang.org/doc/faq#get_version
+4
Ужас :( К сожалению, для меня это реально блокер, буду дальше писать на Java/Kotlin, думал для бэкендовых вещей попробовать Go
В godeps так и не увидел, как указать версию зависимости.
gpm это позволяет, но рекомендации по использованию gpm для CI просто убили:
В godeps так и не увидел, как указать версию зависимости.
gpm это позволяет, но рекомендации по использованию gpm для CI просто убили:
Скрытый текст
## With wget
$ wget -qO- https://raw.githubusercontent.com/pote/gpm/v1.3.2/bin/gpm | bash
## With cURL
$ curl -s https://raw.githubusercontent.com/pote/gpm/v1.3.2/bin/gpm | bash
-4
Для бекендовых вещей Go вообще идеальный вариант.
Все-таки, по моему опыту — главная проблема для входа в Go — это стереотипы из других языков. В Go-комьюнити нет проблемы с backward-compatibility, поэтому в подавляющем большинстве случаев использовать свежую версию — это ок, и до сих пор проблем не вызывало. Ну а для приватных проектов, где нужно иметь 100% гарантию — все равно лучше копирования локально (особенно с помощью vend) ничего нет.
Все-таки, по моему опыту — главная проблема для входа в Go — это стереотипы из других языков. В Go-комьюнити нет проблемы с backward-compatibility, поэтому в подавляющем большинстве случаев использовать свежую версию — это ок, и до сих пор проблем не вызывало. Ну а для приватных проектов, где нужно иметь 100% гарантию — все равно лучше копирования локально (особенно с помощью vend) ничего нет.
+1
Используйте стандартный Workspace, который описывал divan0 в одной из своих статей и дополните его менеджером Nut, который позволит вам контролировать версии зависимостей. С большим условием, если это действительно так вам важно, особенно, не доверие к способу установки gpm.
В среднем проекте — внешних пакетов достигает не больше 5-ти и если важна стабильность, то вы просто форкаете нужную версию к себе и используете хоть всю жизнь :)
Использование менеджеров происходит обычно в команде, когда другому человеку не потребуется заботиться о том, что ввели новый внешний пакет или другую его версию. Он просто выполнит команду для обновления текущих пакетов в его локальном окружении для проекта.
В среднем проекте — внешних пакетов достигает не больше 5-ти и если важна стабильность, то вы просто форкаете нужную версию к себе и используете хоть всю жизнь :)
Использование менеджеров происходит обычно в команде, когда другому человеку не потребуется заботиться о том, что ввели новый внешний пакет или другую его версию. Он просто выполнит команду для обновления текущих пакетов в его локальном окружении для проекта.
+1
Ну так скачайте нужную версию самостоятельно, в чём особенная разница?
+1
Это не больший «блокер», чем использование npm в ноде, которая тоже не часть node.js как такового. Такие вещи совершенно не обязаны поддерживаться на уровне языка, они прекрасно реализуются сторонними приложениями. Go сам по себе даёт концепцию GOPATH, а какие версии и как вы в него положите — это ваше дело и ваша свобода. Инструментов для точного контроля версий — масса github.com/golang/go/wiki/PackageManagementTools
+2
Спасибо большое за ссылку, я понимаю, что это не упрёк к языку, просто Go один из немногих, который из коробки имеет менеджмент зависимостей, буду изучать альтернативные менеджеры зависимостей.
0
Ну и от меня совет — займитесь менеджером зависимостей, когда у вас уже будет код. Это абсолютно безболезненная операция — её можно делать в любой момент, зато реальный опыт работы немножко прояснит специфику работы с пакетами в Go — возможно вы понизите «блокер» на «найс ту хэв»))
+1
Да, не спорю, совет правильный. Просто хочу снизить количество граблей в разработке на этапе компиляции выбора языка/инструментов.
Пока для меня Go — вариант для написания микросервисов, с Java/Kotlin всё ок, но поднимаешь это в каком-нибудь томкате и мегабайт 300 памяти сразу отожрано, грустно от этого.
P.S.
Тут так все негативно отнеслись к фиксированию версий зависимостей, я аж себя старовером почувствовал из-за того, что работаю в команде, с CI и хочу, чтобы у всех всё билдилось одинакого без сайд эффектов. Копировать исходники или заводить кучу сабмодулей это тоже не вариант, конечно.
Извиняюсь, что нафлудил тут, спасибо за ответы!
Пока для меня Go — вариант для написания микросервисов, с Java/Kotlin всё ок, но поднимаешь это в каком-нибудь томкате и мегабайт 300 памяти сразу отожрано, грустно от этого.
P.S.
Тут так все негативно отнеслись к фиксированию версий зависимостей, я аж себя старовером почувствовал из-за того, что работаю в команде, с CI и хочу, чтобы у всех всё билдилось одинакого без сайд эффектов. Копировать исходники или заводить кучу сабмодулей это тоже не вариант, конечно.
Извиняюсь, что нафлудил тут, спасибо за ответы!
+1
Почему не вариант? Это как раз самый надежный вариант, потому как сторонние библиотеки потенциально могут быть удалены.
Version pinning это хорошо, но это не спасет от того, если автор решил удалить библиотеку.
Ну и ещё, чтобы вы понимали причины отсутствия этого дела в «Go из коробки» — это, по определению, сложная задача. Которую, без усложнения всего инструментария красиво не сделаешь. Поэтому, следуя принципу KISS, авторы Go оставили потенциальную разработку продвинутых менеджеров версий/зависимостей сообществу. Это open-source в конце концов — если кто-то предложит решение, которое всех устраивает и всем нравится — его добавят.
Version pinning это хорошо, но это не спасет от того, если автор решил удалить библиотеку.
Ну и ещё, чтобы вы понимали причины отсутствия этого дела в «Go из коробки» — это, по определению, сложная задача. Которую, без усложнения всего инструментария красиво не сделаешь. Поэтому, следуя принципу KISS, авторы Go оставили потенциальную разработку продвинутых менеджеров версий/зависимостей сообществу. Это open-source в конце концов — если кто-то предложит решение, которое всех устраивает и всем нравится — его добавят.
0
В мире Java есть такие вещи, как mavenCentral из которого запрещено удаление опубликованных артефактов, bintray вроде как позволяет.
Копирование не вариант — потому что это зло by default, потом еще обычно кто-нибудь меняет исходники библиотеки и всё, фиг обновишься нормально.
А сабмодули это ад и зло при командной разработке, вечно надо git submodule update или как там, аж муражки, как вспомню
Интересно, есть ли у Go вариант собирать исходники в .zip и сделать общий репозиторий из которого нельзя удалять добавленное, а на клиенте просто название артефакта + версия, вот это красота и удобство.
Вот такое имхо
Копирование не вариант — потому что это зло by default, потом еще обычно кто-нибудь меняет исходники библиотеки и всё, фиг обновишься нормально.
А сабмодули это ад и зло при командной разработке, вечно надо git submodule update или как там, аж муражки, как вспомню
Интересно, есть ли у Go вариант собирать исходники в .zip и сделать общий репозиторий из которого нельзя удалять добавленное, а на клиенте просто название артефакта + версия, вот это красота и удобство.
Вот такое имхо
-1
Я не сильно понимаю ваш юз-кейс, и, судя по минусам, народ тоже не очень.
«потом еще обычно кто-нибудь меняет исходники библиотеки и всё, фиг обновишься нормально.» — это как?
Есть системы контроля версий, а тем, кто «меняет исходники библиотеки» — дать по ушам. А если по делу поменял — то это изменение автоматически у всех девелоперов появляется, не нужно никаких дополнительных телодвижений.
Ну и еще раз — вот вы прописали версии, зависимости, научили всех девелоперов в тиме этим менеджеров зависимостей пользоваться — а тут раз, автор библиотеки перенес код в другой URL или вообще, удалил. Как вы получите «гарантированно такой же код»?
Вобщем, рекомендую немножко покопать на эту тему — все таки народ не с потолка берет такие схемы менеджмента зависимостей. И копирование — ничуть не зло, by default. Дисковое пространство нынче дешевое, а время разработчиков — дорогое.
«потом еще обычно кто-нибудь меняет исходники библиотеки и всё, фиг обновишься нормально.» — это как?
Есть системы контроля версий, а тем, кто «меняет исходники библиотеки» — дать по ушам. А если по делу поменял — то это изменение автоматически у всех девелоперов появляется, не нужно никаких дополнительных телодвижений.
Ну и еще раз — вот вы прописали версии, зависимости, научили всех девелоперов в тиме этим менеджеров зависимостей пользоваться — а тут раз, автор библиотеки перенес код в другой URL или вообще, удалил. Как вы получите «гарантированно такой же код»?
Вобщем, рекомендую немножко покопать на эту тему — все таки народ не с потолка берет такие схемы менеджмента зависимостей. И копирование — ничуть не зло, by default. Дисковое пространство нынче дешевое, а время разработчиков — дорогое.
0
По моему в go можно сослаться на тег в github. Его никто менять не будет.
0
Похоже, что в Go через пару минорных версий будет свой фиксатор зависимостей: groups.google.com/forum/#!topic/golang-dev/nMWoEAG55v8%5B1-25%5D
0
Как пройти пятую миссию?)
0
Напомните, что там? Там произвольно между миссиями нельзя переключаться, чтобы посмотреть.
0
5: Into the Open
просто проверяйте код функцией isCorrect перед тем как добавлять его в массив
переключаться между уровнями можно если навеcти на аватарку — levels
просто проверяйте код функцией isCorrect перед тем как добавлять его в массив
переключаться между уровнями можно если навеcти на аватарку — levels
+1
Не, уже не могу переключаться — я сделал Reset, чтобы заскриншотить первый левел.
0
там оказывается и рейтинг есть: gocode.io/about (и судя по всему многие как и я нажали run перед тем как прочитать что на 12 миссию одна попытка)
0
А для других языков такого нет?
0
Без понятия. Автор делал эту игрушку для конкурса Gopher Gala, правда не успел немного, и только вчера выкатил.
0
Есть ещё вот такое с самописным языком: www.hackedapp.com/
Геймплей состоит в написании алгоритмов, проходящих юнит-тесты, ожидающие определённого вывода на определённый ввод. Причём часть юниттестов скрыто, чтоб просто пачкой if IN_k return OUT_k не обойтись.
Геймплей состоит в написании алгоритмов, проходящих юнит-тесты, ожидающие определённого вывода на определённый ввод. Причём часть юниттестов скрыто, чтоб просто пачкой if IN_k return OUT_k не обойтись.
0
Ооооо, есть же http://www.codingame.com/.
+1
Есть такая для Ruby: www.bloc.io/ruby-warrior
0
Кто-нибудь понял как ребята из топа зарабатывают score равный 2147483647? Это какой-то баг или я что-то пропустил?
0
Go, я создал!
0
Как пройти 7-й уровень, используя данные канала, который хотим перехватить? Я схитрил и просто заполнил свой канал таким же образом, как и заполняется перехватываемый. Хотелось бы понять, как решить иначе.
0
Застрял на 11-ом задании. Трудновато у меня как-то с GO. Вот бы было что-нибудь подобное на С++.
Намекните хотя бы как пройти 11ое задание «Phone Home»
Намекните хотя бы как пройти 11ое задание «Phone Home»
0
Структура Signal полностью в вашей власти, вы можете делать с ней всё что угодно, ну и golang.org/pkg/encoding/json/#Marshal (это намёк, в описании можно найти необходимую информацию)
+1
Как пройти 10-й уровень (Epoch's Trap), дайте подсказку. Оператор return нельзя использовать, как тогда я смогу переопределить метод, чтоб он вернул true?
0
Какое имя должно быть в 3 миссии?
0
Игра переместилась на URL: www.andybrewer.com/operation-go
0
Игра теперь находится по ссылке https://andybrewer.github.io/operation-go/
0
Only those users with full accounts are able to leave comments. Log in, please.
Operation Go — игра-боевик для Go-программистов