Apt-get no Mac? Gerenciadores de pacotes para o OS X

Augusto Campos em 18/09/2012

Gerenciador de pacotes para o Mac é o tipo de solicitação frequente de quem chega ao OS X vindo do mundo Linux e de outros ambientes em que são comuns soluções como o apt-get, yum, ports e similares.

Para instalar boa parte dos pacotes (tipicamente open source) providos por eles (nomes como ffmpeg, gawk, ImageMagick, wget e muitos outros são exemplos), a minha preferência pelo Rudix já foi revelada nas primeiras semanas de atividade do BR-Mac (no artigo Rudix: pacotes GNU e para UNIX adicionais para o Mac).

E não prefiro o Rudix apenas por se tratar da obra de um brasileiro que o mantém desde 2005 e cujas demais atividades tecnológicas acompanho de longa data: ele tem a vantagem de trazer os softwares em questão empacotados no "estilo Mac", dispensando a instalação prévia de ferramentas de desenvolvimento, diretórios especiais e outros recursos comuns às alternativas.

A instalação dos pacotes via Rudix pode ocorrer da forma usual no Mac (faz o download do pacote desejado e clica no arquivo) ou da forma típica dos terminais, digitando algo como sudo rudix install nome-do-pacote.

As alternativas tradicionais

Se eu fosse usar algum dos gerenciadores de pacotes tradicionais voltados ao Mac, preferiria o MacPorts, que tem laços fortes com o desenvolvimento do Darwin, participação direta da Apple e de uma figura que eu admiro especialmente: Jordan K. Hubbard, que é co-fundador do FreeBSD (onde também fundou a coleção de ports) e hoje atua na Apple.

Mas quando se trata desta categoria de utilitário, há bastante amplitude de atuação das preferências de cada um, e em um artigo da semana passada vimos o relato de um usuário que prefere o homebrew, por exemplo.

Eles têm suas similaridades e também seus diferenciais, mas ambos têm comandos com um visual familiar, como nos exemplos:

  • brew install gawk
  • sudo port install lynx

A escolha de um deles pode se basear no critério que você preferir: use o que alguém que você confia prefere, teste ambos, consulte opiniões on-line, compare especificações, etc.

Mas para instalar qualquer um deles, sugiro começar por este artigo de ontem na MacLife que apresenta as linhas gerais de ambos, os requisitos de instalação e até os procedimentos (ou referências) necessários.

E boas instalações!

Comentar

Comentários arquivados

Comentário de diego em 18/09/2012 às 10:43:27

Também gosto do rudix mas aparentemente o homebrew tem mais pacotes à disposição (tinha alguns que eu precisava e não estavam no rudix pelo menos), foi o que me fez mudar. E o brew não usa sudo :)

Comentário de Augusto Campos em 18/09/2012 às 10:54:03

Grato, vou remover o sudo do exemplo ツ

Comentário de Thiago A. em 18/09/2012 às 13:01:23

Para quem usa git acho o homebrew mais interessante, pois é tecnologia principal que ele usa por trás. Uma das coisas que gosto nele é que os pacotes não ficam espalhados pelo sistema, e por padrão ficam em /usr/local/Cellar - daí o homebrew cria links simbólicos em /usr/local/bin. Faz parte da filosofia dele não incluir por padrão nos repositórios o que já vem no Mac, mas existem casos que você precisa de um pacote com uma flag especial, por exemplo, vim com suporte à Ruby. Nesse caso é só instalar o repositório de duplicados que está hospedado no GitHub: brew tap homebrew/homebrew-dupes # Adiciona repositório de duplicados, útil para compilar um pacote com uma flag especial ou se você precisa sempre da última versão de um pacote brew tap josegonzalez/homebrew-php # Instala repositório não oficial de versões do PHP

Comentário de Brunno dos Santos (@squiter) em 18/09/2012 às 17:48:07

Para desenvolvimento o homebrew costuma ser muito mais popular. Todo bom desenvolvedor que escreve em blogs ou ajuda em projetos opensource usa o brew como exemplo. Eu uso o Macports, e já tive vários problemas com ele, prncipalmente usando RVM junto... só não mudei ainda pro brew porque meu ambiente já está funcionando perfeitamente com o ports e no momento não posso me dar o luxo de mudar isso.

Comentário de Tiago em 18/09/2012 às 18:54:31

Ter que depender disso sempre foi a minha maior critica do Linux. Poxa, no Linux eu não posso simplesmente fazer um download e usar. Tem toda uma via crusis de ver se o software existe no repositório, se não existe, procurar por um repositório compatível, e se não achar, compilar. Simplesmente eu não posso clicar na po**a do link e instalar o software. Então, porque andar para trás? Se no Mac não existe esse problema, para criá-lo? Sinceramente, eu não vejo nenhum motivo nisso. E outra, software que vc usa está sempre atualizado porque ele sempre se verifica. Logo, atualização de software não é justificativa. Então, para que isso?

Comentário de Augusto Campos em 18/09/2012 às 19:43:37

Tiago, mas é assim mesmo que funciona: você não vê nenhum motivo para usar, você não precisa usar, portanto você não deve usar. Especialmente se os autores dos programas que você deseja usar mantiverem uma versão que cuide de sua própria atualização, instalável da forma tradicional do desktop Mac, em um link no qual você possa clicar e instalar. Mas o seu caso de uso não é o único. As ferramentas estão ali disponíveis para os demais casos (para quem quer usar, ou fora do desktop, ou ainda para programas cujos autores não providenciam versões empacotadas ou auto-atualizáveis), e isso não gera qualquer justificativa de sua existência para quem não tem demanda por elas.

Comentário de Andre em 21/09/2012 às 18:58:32

O que mais me atraiu no HomeBrew foi a organização dos arquivos (dentro dos kegs, com links simbólicos no /usr/local) e não precisar de permissões de root para instalar os aplicativos. Você pode inclusive ter várias versões do mesmo aplicativo instaladas. Outra coisa interessante é a facilidade de criar recipes para aplicativos que não estão no repositório oficial. Na maioria dos casos, um: brew create "url para o source" já é suficiente. :)

Comentário de Vandrei Jaques em 02/04/2013 às 02:25:56

Muito interessante o MacPorts, ainda não utilizei nenhum software instalado por ele, mas já atualizei a base de dados hehehe.