Quelle est la différence / utilisation des homebrews, macports ou autres outils d'installation de packages? [fermé]

239

Je viens récemment de passer à un Mac d'Ubuntu. J'ai été déçu que mac n'ait pas la commodité sudo apt-getdans Ubuntu. J'ai entendu dire que je devrais utiliser homebrew mais je ne sais pas exactement ce que fait homebrew ou macports?

ROBOTPWNS
la source
4
beaucoup de liens: apple.stackexchange.com/questions/32724/…
cregox
8
Il y a quelques années, la porte d'entrée de l'homebrew avait une déclaration qui disait quelque chose comme ceci: "homebrew est mieux parce qu'il est écrit en Ruby". Je n'ai rien contre Ruby, pas du tout. J'aime oop et rubis est une belle langue oop. Ce qui me pose problème, c'est tout développeur de logiciels qui pense qu'une langue est meilleure que toutes les autres. Pour cette seule raison, je n'ai aucun intérêt pour les homebrews. De plus, macports fonctionne bien pour moi depuis de nombreuses années.
Mike Makuch du

Réponses:

146

MacPorts est la voie à suivre.

  1. Comme l'a indiqué @ user475443, MacPorts propose de nombreux autres packages. Avec l'infusion, vous vous retrouverez rapidement pris au piège car la formule dont vous avez besoin n'existe pas.

  2. MacPorts est une application native: C + TCL. Vous n'avez pas du tout besoin de Ruby. Pour installer Ruby sur Mac OS X, vous pourriez avoir besoin de MacPorts, alors optez simplement pour MacPorts et vous serez heureux.

  3. MacPorts est vraiment stable, en 8 ans, je n'ai jamais eu de problème avec ça, et tout mon écosystème Unix le relais.

  4. Si vous êtes un développeur PHP, vous pouvez installer la dernière version d'Apache (Mac OS X utilise 2.2), PHP et toutes les extensions dont vous avez besoin, puis mettre à niveau le tout avec une seule commande. Oubliez de faire de même avec Homebrew.

  5. Groupes de soutien MacPorts.

    foo@macpro:~/ port select --summary
    
    Name        Selected      Options
    ====        ========      =======
    db          none          db46 none
    gcc         none          gcc42 llvm-gcc42 mp-gcc48 none
    llvm        none          mp-llvm-3.3 none
    mysql       mysql56       mysql56 none
    php         php55         php55 php56 none
    postgresql  postgresql94  postgresql93 postgresql94 none
    python      none          python24 python25-apple python26-apple python27 python27-apple none
    

    Si vous avez installé PHP55 et PHP56 (avec de nombreuses extensions différentes), vous pouvez permuter entre eux avec une seule commande. Toutes les extensions relatives font partie du groupe et elles seront activées au sein du groupe choisi: php55 ou php56. Je ne suis pas sûr que Homebrew dispose de cette fonctionnalité.

  6. Les rubistes aiment tout réécrire dans Ruby, car la seule chose qu'ils sont à l'aise est Ruby lui-même.

nom
la source
26
Les rubistes aiment réécrire - hehe, jetez un œil aux gars de NodeJS qui implémentent des protocoles binaires pour MySQL dans JS! :)
kolypto
37
Vous n'avez pas besoin de MacPorts pour installer Ruby - Ruby est inclus avec OS X, et brew utilise le système Ruby.
Michael Ekstrand
5
@Michael Ekstrand OS X n'inclut pas la dernière version de Ruby.
nom
89
Je ne peux pas voter positivement. C'est trop sarcastique, et le sarcasme sape l'information.
OldPeculier
34
Voter pour contrer les upvotes «anti-snarky» omis. Toute information reçue d'un être humain aura toujours un biais naturel ("snarkiness" dans ce cas). J'apprécie le point de vue de cet utilisateur, peut-être spécifiquement parce que la réponse ne se lit pas comme une entrée wikipedia.
rinogo
109

Homebrew et macports résolvent tous deux le même problème - c'est-à-dire l'installation de bibliothèques et d'utilitaires communs qui ne sont pas fournis avec osx.

Il s'agit généralement de bibliothèques liées au développement et l'utilisation la plus courante de ces outils est destinée aux développeurs travaillant sur osx.

Ils ont tous deux besoin que les outils de ligne de commande xcode soient installés (que vous pouvez télécharger séparément sur https://developer.apple.com/ ), et pour certains packages spécifiques, vous aurez besoin de l'intégralité de l'IDE xcode installé.

xcode peut être installé à partir du Mac App Store, c'est un téléchargement gratuit, mais cela prend un certain temps depuis environ 5 Go (si je me souviens bien).

macports est une version osx de l'utilitaire de port de BSD (comme osx est dérivé de BSD, c'était un choix naturel). Pour quiconque connaît l'une des distributions BSD, macports se sentira comme chez lui.

Une différence majeure entre homebrew et macports; et la raison pour laquelle je préfère l'homebrew est qu'il n'écrasera pas les choses qui devraient être installées "nativement" dans osx. Cela signifie que si un package natif est disponible, homebrew vous en informera au lieu de le remplacer et de causer des problèmes plus loin. Il installe également des bibliothèques dans l'espace utilisateur (ainsi, vous n'avez pas besoin d'utiliser "sudo" pour installer des choses). Cela aide également à se débarrasser des bibliothèques, car tout est dans un chemin d'accès qui vous est accessible.

homebrew bénéficie également d'une communauté d'utilisateurs plus active et ses packages (appelés formules) sont mis à jour assez souvent.


macports ne remplace pas les packages OSX natifs - il fournit sa propre version - C'est la principale raison pour laquelle je préfère macports au brassage maison, vous devez être certain de ce que vous utilisez et du changement d'Apple à différents moments des ports et avoir été connu être des années derrière les mises à jour dans certains projets

Pouvez-vous donner une référence montrant que macports écrase les packages OS X natifs? Autant que je sache, toute l'installation de macports se produit dans /opt/local

Je devrais peut-être préciser - je n'ai dit nulle part dans ma réponse que macports écrase les packages natifs OSX. Ils installent tous les deux des éléments séparément.

Homebrew vous avertira lorsque vous devez installer les choses "nativement" (en utilisant l'installateur préféré de la bibliothèque / de l'outil) pour une meilleure compatibilité. Voilà ce que je voulais dire. Il utilisera également autant de bibliothèques locales disponibles dans OS X. Depuis le wiki :

Nous n'aimons vraiment pas les dupes en Homebrew / homebrew

Cependant, nous aimons les dupes dans le robinet!

Les trucs fournis avec OS X ou une bibliothèque fournie par RubyGems, CPAN ou PyPi ne doivent pas être dupés. Il y a de bonnes raisons pour ça:

  • Les bibliothèques en double cassent régulièrement les builds
  • Des bogues subtils émergent avec des bibliothèques en double et, dans une moindre mesure, des outils en double
  • Nous voulons que vous fassiez plus d'efforts pour que votre formule fonctionne avec OS X

Vous pouvez éventuellement remplacer les versions d'utilitaires fournies par macosx avec homebrew.

Burhan Khalid
la source
78
macports ne remplace pas les packages OSX natifs - il fournit sa propre version - C'est le principal rason que je préfère macports au brassage maison, vous devez être certain de ce que vous utilisez et du changement d'Apple à différents moments des ports et avoir été connu être derrière les mises à jour dans certains projets
mmmmmm
13
Pouvez-vous donner une référence montrant que macports écrase les packages OS X natifs? Autant que je sache, toute l'installation de macports se produit dans/opt/local
27
Vous avez au moins laissé entendre très fortement que MacPorts écrase les packages OS X natifs. Au lieu de "clarifier" tout en prétendant que vous n'avez pas dit avoir écrit ce que vous avez écrit, vous devriez probablement modifier la phrase en question.
Relax
13
Cette phrase, "Une différence majeure entre homebrew et macports; et la raison pour laquelle je préfère homebrew est qu'il n'écrasera pas les choses qui devraient être installées" nativement "dans osx." devrait être remplacé par "Une différence majeure entre homebrew et macports; et la raison pour laquelle je préfère homebrew est que homebrew n'installera pas automatiquement des copies parallèles d'outils et de bibliothèques qui sont déjà fournis par Apple."
bgupta
7
MacPorts n'écrase pas les applications natives, il "confine les logiciels portés à un" bac à sable "privé qui l'empêche de se mêler à votre système d'exploitation et à ses logiciels fournis par le fournisseur pour les empêcher d'être corrompus." - Guide MacPorts, Chapitre 1
jla
23

Actuellement, Macports a beaucoup plus de packages (~ 18,6 K) qu'il n'y a de formules Homebrew (~ 3,1 K), en raison de sa maturité. Homebrew rattrape lentement cependant.

Les packages Macport sont généralement gérés par une seule personne.

Macports peut conserver plusieurs versions de packages, et vous pouvez les activer ou les désactiver pour tester les choses. Parfois, cette liste peut être corrompue et vous devez la modifier manuellement pour remettre les choses en ordre, bien que ce ne soit pas trop difficile.

Les deux gestionnaires de packages demanderont à être régulièrement mis à jour. Cela peut prendre un certain temps.

Remarque: vous pouvez avoir les deux gestionnaires de packages sur votre système! Ce n'est ni l'un ni l'autre. Brew pourrait se plaindre, mais Macports ne le fera pas.

De plus, si vous traitez avec des packages python ou ruby, utilisez un environnement virtuel dans la mesure du possible.

user475443
la source
1
{{{Parfois, cette liste peut être corrompue et vous devez la modifier manuellement pour remettre les choses en ordre, bien que ce ne soit pas trop difficile. }}} Je n'ai jamais vu cela se produire, mais cela ne veut pas dire que ce n'est pas possible. Quelles étaient les circonstances? Avez-vous signalé un bogue ( trac.macports.org )?
LSpice
{{{Les deux gestionnaires de packages demanderont à être régulièrement mis à jour. Cela peut prendre un certain temps. }}} Cela semble être une déclaration étrange. En plusieurs années d'utilisation, je ne me souviens que de la mise à niveau de MacPorts elle-même quelques fois, et la mise à jour est plutôt rapide. Voulez-vous dire que les ports eux-mêmes doivent être mis à jour fréquemment? Eh bien, ils peuvent l' être, mais c'est une bonne chose, pas un inconvénient, je pense! En outre, il convient probablement de noter que MacPorts ne demandera rien, c'est-à-dire qu'il n'y a pas de harcèlement; vous devez demander ce sur les paquets hors de ce jour.
LSpice
18

Par défaut, Homebrew installe les packages sur votre / usr / local. Les commandes Macport nécessitent sudo pour l'installation et la mise à niveau (similaire à apt-get dans Ubuntu).

Pour plus de détails:

Ce site suggère d'utiliser Hombrew: http://deephill.com/macports-vs-homebrew/

alors que ce site répertorie les avantages de l'utilisation de Macports: http://arstechnica.com/civis/viewtopic.php?f=19&t=1207907

J'ai également récemment quitté Ubuntu et j'aime utiliser les homebrews (c'est simple et facile à utiliser!), Mais si vous vous sentez attaché à l'utilisation de sudo, Macports pourrait être la meilleure solution!

debstep
la source
4
Voulez-vous dire que homebrew installe des choses /usr/localsans nécessiter sudo?
1
@NgocPham Avez-vous une référence pour cela?
16
@Keith Ce site est incorrect. Ou du moins, cela laisse de côté une prémisse majeure. Il dit "Apple a laissé ce répertoire pour nous. Ce qui signifie qu'il n'y a pas de répertoire / usr / local par défaut, donc vous n'avez pas à vous soucier de gâcher les outils existants." Apple n'est pas parti /usr/localpour Homebrew. Apple est parti /usr/localpour les "exécutables, bibliothèques, etc. non inclus dans le système d'exploitation de base". Cela signifie qu'il est possible que les outils installés avant d'utiliser Homebrew aient créé de /usr/localtelle sorte qu'il ne puisse pas être modifié sans sudo. Ils n'en discutent pas sur le wiki.
2
@NgocPham Mon point est que je ne crois pas que Homebrew puisse utiliser /usr/localsans les autorisations root. Les autorisations par défaut pour /usrune nouvelle installation d'OS X sont le propriétaire de la racine, sans autorisation d'écriture pour quiconque. Pour même créer /usr/local , Homebrew aurait besoin d'un accès root. (Je
5
@Articuno Je pense que je t'ai eu maintenant. C'est juste l'instruction qui homebrewpeut installer des trucs sans sudoparce que quand il s'est installé, il a utilisé sudo pour rendre l'autorisation sur le répertoire plus lâche afin qu'il puisse faire n'importe quoi à l'intérieur /usr/localsans déclencher le mot de passe. Cela signifie-t-il que la partie «installer sans mot de passe» est erronée? Je ne pense pas! Il est encore vrai que homebrew sera en mesure d'obtenir des choses sans le mot de passe.
Ngoc Pham