Почему Erlang не приходит с приличной системой управления пакетами, как gem? [закрытый]
Ладно, это звучит немного напыщенно, но мне было интересно, есть ли техническая причина, по которой Erlang не имеет надлежащей системы управления пакетами по умолчанию.
2 ответа:
На самом деле никакой серьезной технической причины нет. Просто разные потребности, так как классический способ настройки и установки программного обеспечения erlang-это приложения. И некоторые релизы использования добавили к этому.
Часто вы видите, что программное обеспечение erlang распространяется полностью самостоятельно. Это означает, что он содержит все библиотеки и виртуальную машину вместе в пакете и не нуждается в каких-либо внешних зависимостях. Вы даже видите это в версиях разработки пакетов. Исходное дерево базы данных Riak например, в нем есть все зависимые библиотеки.
Это не такая уж плохая идея, как могут подумать многие выходцы из Ruby(вроде меня). Таким образом, каждое приложение является самостоятельным. Поскольку одна из главных целей Erlang-быть самой надежной доступной вещью, есть все основания полагать, что каждое приложение может иметь свою собственную версию библиотеки. Таким образом, убедившись, что одно приложение не делает другое нестабильным.
Try rebar; это система сборки для erlang, которая включает в себя систему управления зависимостями. У него нет центрального хранилища, как камень с rubygems.org, так что вы должны указать URL ЖКТ. Но это избавит вас от необходимости загружать вложенные deps; он сам позаботится об этом.
И он придерживается философии Erlang, сохраняя загруженные deps внутри каталога проекта, а не в Центральном системном расположении; это похоже на развертывание bundler режим.