Если вы разработчик на PHP, то скорее всего используете в своих проектах менеджер пакетов Composer. При выполнении команд create-project, require, update, remove, Composer загружает из сети информацию о необходимых пакетах, а также об их зависимостях. Количество загружаемых json-файлов зависит от сложности используемых пакетов. Чем дальше вы находитесь от физического местоположения сервера packagist.org или его зеркал, тем больше времени требуется для разрешения зависимостей. Использование российского зеркала поможет ускорить вашу работу.
Emacs'ом я пользуюсь уже довольно давно и в общем-то для всего подряд. Хотя число elisp-пакетов распространяемых вместе с этим текстовым комбайном растет постоянно, иногда все же приходится устанавливать сторонние пакеты. Со временем их количество тоже постепенно растет, для них приходится отслеживать зависимости, их также необходимо (или желательно) обновлять, в общем, стандартный набор задач для менеджера пакетов. До недавнего времени для установки elisp-пакетов я пользовался системными пакет-менеджерами под linux типа apt, portage. Определенные неудобства конечно были, но настоящие проблемы начались когда Emacs пришлось использовать под Windows и Mac OS. Кроме собственно управления пакетами, появилась необходимость синхронизировать все установленные файлы, а не только настройки в ~/.emacs.
В итоге я созрел для использования полноценного менеджера elisp-пакетов, желательно обладающего следующими качествами:
большая база пакетов
удобство создания и поддержания собственных пакетов
легкость синхронизации установленных пакетов между компьютерами
кросс-платформенность без установки дополнительных приложений
После небольшого исследования существующих возможностей получился этот обзор, в котором я подробно на остановлюсь на elpa и el-get, а также кратко расскажу о других.
По долгу службы мне уже полтора года доводится писать для платформы Android, и вроде бы знания мои в данной области обширны, но и на хабре объем уже охваченных тем не мал. В общем-то после долгих рассуждений решил я поведать хабралюдям о данной теме.
Всем привет! Одним из моих любимых языков является Go, в результате чего я задумался о написании чего-то вроде Package Manager… Ну или хотя бы поисковика пакетов. Есть идея, пора бы сесть за разработку. Конечно же в первую очередь я подумал о Go как о инструменте для решения проблемы. Но, немного поразмыслив, решил дать шанс манящему меня PowerShell, за изучение которого я садился уже раза 3, но что-то меня постоянно останавливало (скорее всего лень и отсутствие проектов, которые можно было бы на нем реализовать). Что же, сказано – сделано. Данная статья рассчитана на людей, не знакомых с PowerShell, но имеющих опыт в программировании. Если вам стало интересно, то добро пожаловать под кат.
В этой статье я расскажу, в чем менеджеры зависимостей (package manager) схожи по внутреннему устройству, алгоритму работы, и в чем их принципиальные отличия. Я рассматривал package manager’ы, предназначенные для разработки под iOS/OS X, но содержание статьи с некоторыми допущениями применимо и к другим.
You will learn and create an application-level library in COBOL. You will structure the package, implement automatic tests, deploy on GitHub and enable Continuous Integration workflow. Finally, you will publish the package in the COBOL package registry.
Операционная система OpenWrt обычно используется как прошивка для роутеров. Типичное применение заключается в том, чтобы установить и забыть. Но если вдруг вам чего-то не хватит, то придётся разбираться в устройстве дистрибутива.
OpenWrt использует opkg в качестве пакетного менеджера, точнее, собственный форк. Дебианщикам он во многом покажется знакомым: похожие команды, похожий формат репозитория и пакетов.
Мне захотелось запатчить LUCI (этого в статье не будет), но адекватного быстрого введения я не нашёл, пришлось самостоятельно собирать отрывки сведений из разрозненной документации, статей и примеров, поглядывая в код и на результаты работы. Бонусом собрал примитивный (но бесполезный на практике) пакет, которого ещё нет в репозитории. Собранным ликбезом делюсь ниже.
Прежде чем приступать к написанию кода, нам нужно решить, что именно такого полезного мы можем создать, какие функции будет выполнять библиотека. Довольно популярным является написание библиотек, упрощающих работу с тем или иным API. Зачастую API представляют из себя большой список различных методов, работающих не только через GET method http-протокола.
И это доставляет сложность при работе с ним у программистов: нужно постоянно учитывать все нюансы обращения к методу, его ответа, а еще может присутствовать аутентификация при работе и тд.
У меня есть некоторый опыт в создании пакетов для composer (пример) и я хочу поделиться знаниями с теми кто этого еще не делал. Подробности под катом...
