A2A.
Quel est votre avis sur Homebrew (logiciel)?
Ceci est difficile de répondre pour moi. Je veux vraiment l'aimer, mais il a beaucoup de choses que je considérerais comme des défauts fatals.
Réalisez que les logiciels comme Homebrew sont destinés principalement aux développeurs de logiciels en ligne de commande, et donc qu'ils sont destinés principalement à étendre l'environnement de développement d'un développeur de logiciels.
Il est OK pour faire cela. Il obtient même certaines choses correctes que d'autres choses (par exemple MacPorts) obtiennent mal, comme envelopper les paquets dans une hiérarchie d'installation, puis les installer par liaison symbolique, au lieu de les installer directement.
Pourquoi cet exemple...
J'ai choisi cet exemple en particulier, car j'ai récemment écrit une réponse traitant de la façon dont je configure les systèmes Mac OS X de développeur de mode que j'utilise personnellement pour développer des logiciels. L'une des grandes choses est que j'ai une partition de données séparée sur laquelle vit mon compte utilisateur, et j'ai tendance à y installer mes applications, au lieu de les installer sur la partition de démarrage de l'OS, parce que j'ai tendance à transporter deux partitions de démarrage en même temps.
Je vais en fait transporter 4 partitions de démarrage ou plus lorsque je fais du travail sur le noyau, ce que je faisais surtout lorsque je travaillais chez Apple, car je devais avoir une partition pour la version actuelle, une pour la prochaine version (ce sur quoi je travaillais principalement tout le temps), et une pour la version derrière la version actuelle, afin de pouvoir corriger les bogues du noyau et de sécurité (pour la prochaine mise à jour logicielle). Je pourrais également en emporter deux autres pour une comparaison A/B sur "démarrer cette partition pour obtenir le noyau avec le correctif"/"démarrer cette partition pour obtenir le noyau sans le correctif".
En utilisant l'approche symlink, il est en fait possible de tout mettre sur la partition de données, puis de faire un lien symbolique dans chacune des partitions de démarrage.
Mais vous savez quoi ? Vous pouvez faire cela avec MacPorts, aussi. Parce que /usr/local n'existe pas par défaut, alors autant être un lien symbolique vers un répertoire sur la partition de données, et puis je ne suis pas en train de copier autour des arbres de liens symboliques Homebrew vers un /usr/local sur chaque partition de démarrage.
Alors qu'est-ce que je voulais dire exactement par "il fait certaines choses bien" ?
Primairement, il obtient le numéro de version dans le répertoire dans lequel l'image est construite, de sorte que j'ai le numéro de version de la chose que j'utilise, et je peux choisir entre les versions.
En ajoutant cette couche d'abstraction, Homebrew me protège des choses qui pourraient être confondues en fonction du numéro de version.
Par exemple, en utilisant MacPorts, je pourrais inclure les fichiers d'en-tête d'une bibliothèque version 1.5.11 lorsque je construis quelque chose, puis un autre paquet installe la bibliothèque version 1.7.2, et je me retrouve alors à utiliser la mauvaise bibliothèque avec les mauvais fichiers d'en-tête.
Cela n'arrive pas avec Homebrew.
En supposant que la "recette" de la bibliothèque dans les deux cas est correcte, et que la "recette" des choses qui utilisent la bibliothèque est également suffisamment détaillée. Et la "recette" pour la chose elle-même contourne ou patche le GNU configure pour la chose en cours de construction, de sorte que toutes les références de la bibliothèque et de l'en-tête sont relativement enracinées, et peuvent spécifier les numéros de version.
C'est beaucoup de suppositions, mais quand ça marche, c'est une chose d'une beauté spectaculaire.
À l'inverse, quand ça ne marche pas, c'est aussi assez spectaculaire. Pas dans le bon sens.
Mais j'aime l'abstraction, qui fait de ce qui est apparemment installé une vue plus petite sur ce qui a réellement été construit ou non. La vue peut correspondre exactement, ou la vue peut être une fenêtre beaucoup plus petite sur une chose beaucoup plus grande.
Homebrew a aussi quelques échecs assez mauvais.
Si je veux développer un logiciel qui est basé sur un certain nombre de composants Open Source, Homebrew ne m'aidera à peu près pas pour cela. Je peux le développer dans la hiérarchie, et faire un lien symbolique pour y accéder, mais ce n'est vraiment pas quelque chose que je vais, par exemple, intégrer dans un projet XCode.
Ironiquement : MacPorts est plus d'aide là ... à sa manière ... mais dans les deux cas, je suis coincé à lier statiquement les bibliothèques dans un énorme binaire.
Homebrew finit par être utile pour obtenir des outils pour un développeur, mais ce n'est pas génial d'une autre manière, et je n'ai surtout pas besoin des outils que Homebrew obtient pour moi, à moins que je sois déjà accro à eux.
Si vous venez d'un environnement Linux, et que vous faites un projet ponctuel ou deux sur Mac OS X, et que vous n'utilisez pas l'IDE fourni avec XCode pour faire la plupart de votre travail, alors Homebrew est probablement une bonne voie à suivre pour vous procurer les outils en ligne de commande que vous avez l'habitude d'utiliser sur Linux. Ou BSD, si vous êtes du genre à installer beaucoup de ports sur un système BSD.
Ou vous pourriez juste faire un lien symbolique /usr/local dans un sous-répertoire quelque part, et utiliser MacPorts. Soit l'un soit l'autre.
Quel est, à mon avis, le problème non résolu ?
Ce qui manque à presque tout l'Open Source, c'est un gestionnaire de composants.
On se retrouve avec des choses comme MacPorts et Homebrew quand on essaie d'implémenter un gestionnaire de paquets.
Alors qu'un gestionnaire de paquets peut installer un composant (ou même construire le composant - la plupart des gestionnaires de paquets sont aussi des gestionnaires de configuration), il est assez nul pour gérer les composants.
Si vous obtenez quelque chose comme le système de ports FreeBSD, qui est une extension du système de construction FreeBSD, alors vous finissez par obtenir un gestionnaire de paquets, un gestionnaire de configuration, et un environnement de construction croisée.
Linux est assez pauvre pour fournir un environnement de construction croisée, ce qui est important, si vous voulez, par exemple, construire sur Linux, mais cibler ARM. C'est possible de le faire, mais beaucoup de GNU configure utilise des produits de construction pour traiter le code source dans d'autres produits de construction (l'arbre des périphériques du noyau pour les systèmes ARM/PPC, et pour le noyau lui-même, mais aussi - séparément, sans raison valable - pour CoreBoot, est un bon exemple ici).
Personne ne fournit un gestionnaire de composants.
XCode le fait en quelque sorte. Eclipse le peut, si vous trouvez un tas de plugins obscurs - et renoncez alors à utiliser certains plugins vraiment utiles qui ne peuvent pas faire de ciblage croisé (en supposant que vous utilisez un langage qui compile pour une architecture ou une microarchitecture spécifique, au lieu de Bytecode, comme Java). Microsoft Visual Studio le peut aussi, mais la plupart des composants tiers ne viennent pas en tant que source, et n'ont pas été compilés pour ARM ou d'autres architectures.
Réparer cela nécessiterait de prendre une énorme quantité de projets Open Source, et si ce n'est pas exactement de les forker, de devenir assez profond pour qu'ils vous permettent de mettre vos parties de gestionnaire de composants en eux comme une partie du projet proprement dit.
Si je veux mettre en place un environnement de développement, et qu'il manque des pièces ? Personnellement, je corrige juste les 4 ou 5 bogues de portabilité dans bsd.ports.mk, et j'y arrive. Il n'y a que quelques outils que j'utilise en plus de ceux qui sont installés par défaut lorsque j'installe XCode et les outils de ligne de commande de XCode.
Si j'ai quelqu'un qui vient de Linux, et qui veut un tas d'outils (mais qui est prêt à travailler avec les bibliothèques - même celles de l'Open Source ! - à partir de l'IDE de XCode, alors je recommande Homebrew. C'est comme "apt" pour Linux.
S'ils vont insister pour lier statiquement un tas de choses, et qu'ils sont prêts à construire les bibliothèques dans leur environnement de construction (et je ne recommande jamais, au grand jamais, de faire cela : cela rend vos constructions à peu près aussi reproductibles octet par octet que, disons, Debian Linux avec la réessai de paquet, au lieu des dépendances correctement spécifiées), alors je jette mes mains en l'air et suggère d'aller avec MacPorts.
En résumé?
Si vous êtes un développeur venant de Linux qui veut un tas d'outils, comme (par exemple) la dernière version d'Emacs, et si vous utilisez des composants Open Source dans votre projet mais gérez leurs builds à l'intérieur de XCode - alors Homebrew est probablement pour vous.