Пользователь
0,0
рейтинг
14 февраля 2010 в 15:09

Homebrew: Менеджер пакетов для OS X перевод

Все менеджеры пакетов в Unix имеют определенные недостатки и большинство Linux-дистрибутивов пытаются по-разному эти недостатки обойти. В этом посте я расскажу про Homebrew — новый менеджер пакетов, нацеленный на простоту использования.

До Homebrew было несколько различных попыток создать эффективные пакетные менеджеры для OS X. Две наиболее популярные вылились в итоге в Fink и Macports, но у каждой из них все равно есть свои острые углы. В частности, в обоих создание своих пакетов или портов является черезчур сложным.

В Homebrew создавать новые пакеты и работать с ними проще пареной репы. Давайте посмотрим.

Что оно делает?


Основная мысль очень проста. Homebrew упрощает и автоматизирует монотонные действия по скачиванию и сборке пакетов. Если вам надоели бесконечные ./configure && make && make install, Homebrew поможет.

Зачем оно?


Как я уже заметил выше, для OS X уже есть два решения: Fink и MacPorts. Если какое-то из них у вас уже установлено и всем устраивает — отлично. Но если вы имели неудачный опыт с ними в прошлом, я сильно рекомендую попробовать Homebrew. С ним намного проще. Плюс, его легко модифицировать, ведь он состоит всего из нескольких сотен строк кода на Ruby.

Homebrew не навязывает никакой строгой структуры и путей. По-умолчанию, он устанавливается в /usr/local, но его можно поставить куда угодно. Все пакеты устанавливаются в директории в специальном «подвале» (cellar), например Cellar/git/1.6.5.4/. После установки Homebrew делает симлинки в стандартные Unix-директории. Ручная установка каких-то пакетов не из Homebrew отлично уживается с ними.

Это редко может понадобиться, но пакеты можно ставить напрямую из систем контроля версий. Если у пакета есть публичный git, svn, cvs или mercurial репозиторий, всегда можно собрать самую свежую devel-версию прямо оттуда простым brew install.

Кстати, установка занимает меньше времени, поскольку Homebrew старается избегать дублирования пакетов. Например, она не ставит очередную версию Perl в качестве зависимости, поскольку в системе уже есть готовый и работающий Perl. Плюс, Homebrew задуман так, чтобы вам не приходилось использовать sudo при работе с пакетами.

Звучит неплохо. Как это установить?


Первая и единственная зависимость Homebrew — OS X Developer Tools, которые есть на любом установочном диске с OS X и доступны для бесплатного скачивания с сайта Apple.

Самое простое — установить в /usr/local. Это можно сделать весьма просто:
# Присваиваем папку /usr/local себе, чтобы не использовать sudo
sudo chown -R `whoami` /usr/local
# Чиним права на mysql, если он у вас установлен
sudo chown -R mysql:mysql /usr/local/mysql
# Скачиваем и устанавливаем Homebrew с гитхаба
curl -L github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C /usr/local


Все, установка завершена. Давайте проверим что все работает:
brew install wget
brew info git


На сайте Homebrew есть wiki, где можно почитать всякого интересного про интеграцию с Rubygems, CPAN и Python EasyInstall.

Следить за обновлениями Homebrew тоже достаточно просто:
brew install git
brew update


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

Создавать свои пакеты почти так же просто. Например, если бы в Homebrew не было бы пакета для wget, его создание выглядело бы примерно так:
brew create ftp.gnu.org/gnu/wget/wget-1.12.tar.bz2

После сохранения пакета, его можно протестировать: brew install -vd wget. Если что-то работает неправильно и вам нужна помощь по настройке пакета, на wiki есть много документации. Еще там можно посмотреть примеры создания таких пакетов как git или flac.

Если вы создали новый пакет и желаете поделиться им с сообществом, это тоже достаточно просто сделать с помощью гема github.

gem install json github
git add .
git commit -m "Added a formula for wget"
github fork
git push <ваш_логин_на_github> mastergitx


После того, как вы сделаете push, нужно в Homebrew issue tracker создать новый тикет с темой «New formula: <название_пакета>». Если там все в порядке, ваш пакет будет добавлен в главный репозиторий Homebrew и доступен всем пользователям.

Итоги


Homebrew — достойная альтернатива Fink и MacPorts. Он сам и все скрипты пакетов написанны на Ruby, поэтому добавлять новые фичи и пакеты весьма несложно. Если вам нужен гибкий и удобный пакетный менеджер, попробуйте Homebrew, и, думаю, вы будете приятно удивлены.
Перевод: Andre Arko
rwz @rwz
карма
1,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (51)

  • 0
    Мне MacPorts хватает чуть более чем полностью, а новый менеджер конечно хорошо что появился
    • +2
      У macports есть одна, но большая проблема. Уж очень он любит ставить левые зависимости, которые уже есть в системе (например zlib или openssl). Также порты делать сложнее чем сделать brew create. :)
      • +3
        И perl со всеми его штуками поверх стандартного системного.
        • 0
          Проблема не столько в этом, сколько в том, что большинство системных идет с дефектами/багами/недоработками. Типа PHP release candidate вместо финалки в Snow Leopard или отсутствия поддержки `select.poll` из коробочного питона.
          • 0
            А в маке вообще есть способ завести select.poll на питоне?
            Поставил сейчас 2.5.6 из macports — та же беда.
      • +2
        Проблема частично решается правильной установкой переменных DYLD_LIBRARY_PATH, LD_LIBRARY_PATH и других. В настоящее время мы работаем над новой системой контроля зависимостей, более гибкой и удобной, чем в настоящий момент.
        • 0
          было бы неплохо пощупать :) ждем-с
          • 0
            Одна из основных причин, препятствующих развитию MacPorts — tcl. Из-за того, что язык не самый приятный, разработчики сторонятся проекта. Были попытки переписать/реализовать часть функциональности на Objective C или Ruby, но узкое место — portfiles. Портфайлы написаны на tcl, и без tcl-прослойки их прочитать или сконвертировать не так-то просто.
            • 0
              можно сделать macports 2.0 где портфайлы будут на том же руби, но оставить поддержку tcl (вроде как deprecated). я думаю что если так будет сделано, то портфайлы через некоторое время перепишут на руби. к тому же есть такая штку как ruby-tcl, она еще больше поможет с переходом
              • 0
                Да, именно к этому всё и идёт. Но пока не решен вопрос о том, какой язык использовать для ядра (ObjC или Ruby). У нас коммитеры делятся на ярых противников tcl и на ярых противников скриптовых языков :-)
                • 0
                  тут уже вопрос в распространенности. все таки разработчиков знающих ruby/python больше, чем знающих ObjC
                • 0
                  предлагаю использовать MacRuby
                  • 0
                    имхо не стоит. довольно специфическая вещь, которую тоже надо изучать. я хоть и давно занимаюсь ruby и ObjC, но не сразу бы взялся на этом писать.
                  • 0
                    Ядро работает отдельно от интерфейса. UI уже есть на ObjC написанный.
        • 0
          скажите пожалуйста, Вы один из разработчиков MacPorts?
          • 0
            да.
          • +1
            Хотя сейчас больше WebKit для iPhone. (Mobile Safari dev team).
            • 0
              получается Вы работаете в Apple?
              • +1
                Верно. В данный момент удаленно, я ещё студент. Но сейчас оформляю документы, чтобы весной поехать в Cupertino.
                • 0
                  скажите пожалуйста, а есть надежда, что когда-нибудь MacPort будут в OS X искаробки пакетным менеджером и все будет по-человечески?
                  • 0
                    MacPorts поддерживается Apple'ом, как и XQuartz, x11.app поставляется в комплекте с системой. Возможно, что он будет включен в основной набор. Однако, я не совсем понимаю, если вы говорите о тех проблемах с разными версиями библиотек, то тут нет какого-то универсального метода решения, так как многим библиотекам Mac OS X потребуются именно те версии ПО, которые поставляются. Как я уже говорил, MacPorts не пишет поверх системного ПО, поэтому достаточно подставлять нужные значения env переменных в определенных случаях, и всё будет хорошо.
                    • 0
                      ну вот смотрите. Сейчас у меня есть Leopard Server на PPC. Мне на нём нужен PHP с поддрежкой GD. Поскольку пакетного менеджера искаробки нет, то есть 2 варианта:
                      1. собирать php из исходников с поддержкой всего, что мне надо и замещать им стандартный
                      2. ставить MacPorts, через него устанавливать php5, php5-gd,… и потом прикручить его к стандартному Apache.

                      В Debian я бы просто набрал apt-get install php5-gd и никаких проблем.
                      • 0
                        Apache тоже можно собрать нестандартный. В Debian так возможно, потому что нет бинарных компонентов, в случае OS X пользователь не может перекомпилировать компоненты системы под новые билиотеки. Но кстати, улучшенная поддержка модулей и компонентов для apache в Leopard Server это интересная идея.
                        • 0
                          К сожалению, лучше всего и апач и пхп ставить через MacPorts… То, что по умолчанию в Server версии Mac OS, меня не устраивает… Но тогда теряется возможность управления этим через красивую панельку управления Mac OS Server…

                          Нельзя ли как-то модифицировать GUI, чтобы им можно было управлять Apache'м (и другими компонентами), установленным через MacPorts?
                          • 0
                            Я некомпетентен в этом вопросе. Нужно спросить разработчиков Leopard Server.
        • 0
          Более гибкая система включает в себя поддержку зависимостей с вариантами? Изменятся ли правила сборки расширений для различных скриптовых языков типа python2.x (наподобие python-central или python-support в Ubuntu)?
      • 0
        Зато при обновлении системы ничего гарантировано не отвалится.
  • –6
    Все менеджеры пакетов в Unix имеют определенные недостатки и большинство Linux-дистрибутивов пытаются по-разному эти недостатки обойти. начать с такого и никак не объяснить… моветон…
    • 0
      это перевод. так написано в оригинале, по этому замечание не уместно на мой взгляд :)
      • –2
        и только щас сказали что это перевод?
        • +1
          ну топик вроде бы является переводом раз есть ссылка на автора. к тому же я недавно постил как раз туда ссылку.
          • –2
            в топике нигде не сказано что это перевод
            • +3
              Он помечен иконкой «перевод», а снизу указан автор и ссылка на оригинал.

              Ваш капитан.
              • –2
                мда хабр «очевиден»…
  • 0
    хм… brew update обновляет только «формулы».
    т.е. обновился, например, git, нужно каждый раз это замечатать, на всякий случай смотреть brew info git и делать brew install git заново?
    • 0
      *замечать
    • 0
      Ну таки зачем?
      brew upgrade — обновит все пакеты
      Сории забыл:
      brew cleanup — удалить старые версии пакетов
  • +5
    sudo chown -R `whoami` /usr/local

    вот таким советчикам надо руки отрубать. Я знаю, что так в FAQ написано, но не в инструкции как установить, а в совете как перестать использовать sudo.
    • 0
      ну это там и указано. именно в факе, на гитхабе.
      • +3
        >Звучит неплохо. Как это установить?
        >sudo chown -R `whoami` /usr/local
        vs
        > Installation
        > mkdir homebrew
        > curl -L github.com/mxcl/homebrew/tarball/master | tar xz --strip 1 -C homebrew
        vs
        >But… don't sudo!
        >sudo chown -R `whoami` /usr/local

        у меня все установлено в ~/.homebrew я единственный пользователь которому это надо => для меня не проблема установить в свой домашний каталог только для себя. А портить пермишены, чтобы любая обезьяна попав на мой компьютер могла исполнять все системные бинарники без sudo? нет уж.
        • +1
          если у вас установлено в хомяк, то только вы сможете этим пользоваться, что вполне логично ) в любом случае github.com/mxcl/homebrew/ вам поможет определится, надо вам это или нет
  • 0
    я все-таки еще не очень понял, так этот Homebrew сам прослеживает какие программе нужны зависимости, и в случае необходимости, установит их сам?
  • 0
    Немного оффтоп. У кого-нибудь получилось для MC 7 формулу написать? Два дня бился, собирается но после запуска segfault и все тут.
    • 0
      Я вот такую формулу использую, запускается на 10.6.2 нормально
      require 'formula'

      class Mc <Formula
      url 'http://www.midnight-commander.org/downloads/34'
      md5 '5bd69a47b4a0bd6904623a50863b1eeb'
      homepage 'http://www.midnight-commander.org/'
      version '4.7.1'

      depends_on 'glib'

      def install
      system "./configure", "--prefix=#{prefix}", "--disable-debug", "--disable-dependency-tracking", "--with-screen=ncurses"
      system «make install»
      end
      end
    • 0
      Сорри, плохо получилось. Вот сылка на gist
      gist.github.com/332038
  • 0
    Расскажите кто-нибудь, как установить эти Developer Tools через командную строку, пожалуйста.
    • +1
      Зачем командная строка то? Скачиваешь с сайта, запускаешь установщик, несколько раз тыкаешь в Next и готово.
      • 0
        У меня к серверу нет иного доступа, кроме командной строки.
        • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Кстати, вот неплохой материал про Homebrew, с примерами и чуть более современный :)

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