Постоянное использование мобильного интернета (3G, 4G), в обычном случае — этого хватит на 3-4 часа (2500 mAh).
А тут еще прибавиться какая нибудь беспроводная технология, чтобы принимать сигнал от этой чудо коробочки.
Используйте стандартный Workspace, который описывал divan0 в одной из своих статей и дополните его менеджером Nut, который позволит вам контролировать версии зависимостей. С большим условием, если это действительно так вам важно, особенно, не доверие к способу установки gpm.
В среднем проекте — внешних пакетов достигает не больше 5-ти и если важна стабильность, то вы просто форкаете нужную версию к себе и используете хоть всю жизнь :)
Использование менеджеров происходит обычно в команде, когда другому человеку не потребуется заботиться о том, что ввели новый внешний пакет или другую его версию. Он просто выполнит команду для обновления текущих пакетов в его локальном окружении для проекта.
Вы видимо не работали с менеджером пакетов или не с теми работали. Не могу утверждать, но таковое ощущение создалось.
Отдельных сущностей GOPATH не создается. Всегда есть команда, которая перенаправляет его на текущий проект с которым вы собираетесь работать.
«Ну а второй момент — с выходом за src/ и относительными путями — это уж точно неодобрительная практика.»
Если под «относительными путями» вы подразумеваете указание прямых директорий в импортах, то ничуть этого не происходит, из-за причины, описанной выше.
Так же, когда проект идет в опен-сорс, то он выкладывается в полном виде с приложенным файлом для конкретного менеджера пакетов, чтобы можно было собрать быстро и без боли.
И насчет — «backward-compatibility», не могу вешать никаких ярлыков, но вы живете в слишком прекрасной реальности. Я сам в своих библиотеках ломал зависимости и такое происходило во многих популярных, однако было заметно, когда очень долго пользуешься конкретной библиотекой.
Пардон, из-за того, что в это время работал с продакшеном — допустил ошибки.
Вместо продакшена, я имел ввиду локальное окружение, которое переносится куда нибудь в другое место или передается между разработчиками в своей команде.
Потому что удобство первичного подхода заканчивается на втором проекте.
Обычно, чтобы не скачивать все барахло и не тащить его за собой на продакшен, применяются менеджеры пакетов, а они, как правило — применяются в той самой архитектуре, что я дал выше. Исключений не видел, либо их просто нету.
Вы можете написать, что можно составить список «go get» для себя и использовать его на продакшене, но когда речь заходит о контроле версий существующих пакетов при разработке — то он становится бесполезным.
А тут еще прибавиться какая нибудь беспроводная технология, чтобы принимать сигнал от этой чудо коробочки.
Самое маленькое жаление — это иметь API к:
— Google Play Services
— AdMob
В среднем проекте — внешних пакетов достигает не больше 5-ти и если важна стабильность, то вы просто форкаете нужную версию к себе и используете хоть всю жизнь :)
Использование менеджеров происходит обычно в команде, когда другому человеку не потребуется заботиться о том, что ввели новый внешний пакет или другую его версию. Он просто выполнит команду для обновления текущих пакетов в его локальном окружении для проекта.
Отдельных сущностей GOPATH не создается. Всегда есть команда, которая перенаправляет его на текущий проект с которым вы собираетесь работать.
«Ну а второй момент — с выходом за src/ и относительными путями — это уж точно неодобрительная практика.»
Если под «относительными путями» вы подразумеваете указание прямых директорий в импортах, то ничуть этого не происходит, из-за причины, описанной выше.
Так же, когда проект идет в опен-сорс, то он выкладывается в полном виде с приложенным файлом для конкретного менеджера пакетов, чтобы можно было собрать быстро и без боли.
И насчет — «backward-compatibility», не могу вешать никаких ярлыков, но вы живете в слишком прекрасной реальности. Я сам в своих библиотеках ломал зависимости и такое происходило во многих популярных, однако было заметно, когда очень долго пользуешься конкретной библиотекой.
Вместо продакшена, я имел ввиду локальное окружение, которое переносится куда нибудь в другое место или передается между разработчиками в своей команде.
Обычно, чтобы не скачивать все барахло и не тащить его за собой на продакшен, применяются менеджеры пакетов, а они, как правило — применяются в той самой архитектуре, что я дал выше. Исключений не видел, либо их просто нету.
Вы можете написать, что можно составить список «go get» для себя и использовать его на продакшене, но когда речь заходит о контроле версий существующих пакетов при разработке — то он становится бесполезным.