Homebrew ajoute un avertissement concernant HashiCorp et prévoit une dépréciation

 (github.com/Homebrew)
1 points par GN⁺ 2023-10-09 | 1 commentaires | Partager sur WhatsApp
  • La PR Homebrew/homebrew-core #139538 modifie la formula terraform pour ajouter un avertissement utilisateur en raison du changement de licence de HashiCorp, et signaler qu’elle pourrait être désactivée à terme
  • La raison de ce changement est qu’après ce changement de licence, il n’y aura plus de mises à jour de version de terraform dans homebrew-core ; l’objectif est que les utilisateurs en soient informés au moment de l’installation
  • Lors de la revue, une exception de version a été discutée : de futures versions antérieures à 1.6.0 pourraient être acceptables, même s’il est aussi possible qu’aucune version de ce type n’existe
  • Après nettoyage des dépendances, la PR a été remise en état d’être relue le 4 avril 2024, puis mise à jour avec le commit terraform: deprecate and add caveat pour refléter le retour demandant de supprimer les formulations au futur
  • La modification finale a été fusionnée dans le master de Homebrew le 5 avril 2024 via la merge queue avec le commit 4782218, et la PR connexe de dépréciation de terraform #168090 a également été fusionnée

Dépréciation de la formula terraform et ajout d’un avertissement

  • L’objectif de la PR #139538 était d’informer les utilisateurs que, en raison du changement de licence de HashiCorp, les mises à jour de version de terraform ne seraient plus effectuées dans homebrew-core
  • L’explication initiale visait à prévenir les utilisateurs que cette formula pourrait être désactivée à terme
  • Le fichier visé par la modification était Formula/terraform.rb, puis le chemin a ensuite été affiché comme Formula/t/terraform.rb
  • La PR portait les labels formula deprecated, busl-license, go, maintainer feedback, entre autres

Discussions autour des versions et de la licence

  • Pendant la revue, l’idée a été avancée que, parmi les futures versions de terraform, les versions antérieures à 1.6.0 pourraient être acceptables
    • Il a toutefois aussi été indiqué qu’aucune version de ce type ne verrait peut-être réellement le jour
  • La description de la PR justifiait la modification par le fait qu’après le changement de licence, il n’y aurait plus de mises à jour de version dans homebrew-core
  • Le message de commit a ensuite exprimé l’idée suivante : en raison du changement de licence, il n’y aura plus de mises à jour de version dans homebrew-core, et cette formula sera donc désactivée à terme

Déroulement de la revue et intégration des changements

  • La PR a été ouverte le 14 août 2023, et plusieurs maintainers ont relu les modifications apportées à Formula/terraform.rb
  • Le 6 septembre 2023, un ping a demandé la prise en compte des retours de revue, et l’auteur a indiqué qu’ils avaient été appliqués
  • Le 7 septembre 2023, MikeMcQuaid a approuvé le changement, mais celui-ci a été retiré de la merge queue à cause de l’échec des vérifications d’état
  • Le 20 septembre 2023, chenrui333 a également approuvé le changement
  • Le 23 février 2024, la PR a été marquée comme draft

Nettoyage des dépendances et PR associées

  • Le 13 mars 2024, le commit cdktf: deprecate a référencé cette PR
    • Son message indiquait que cdktf utilisait terraform, sur le point d’être déprécié
    • Il le présentait comme l’une des dernières formulas empêchant encore la dépréciation de terraform
    • Il précisait que cdktf était téléchargé plus de 700 fois par mois et que, bien qu’hébergé dans l’organisation GitHub de HashiCorp, il n’était pas affecté par le changement de licence BUSL
  • La PR associée cdktf: deprecate #166001 a été fusionnée
  • Le 3 avril 2024, atlantis: vendor terraform #167948 a référencé cette PR, puis a été fusionnée

Récapitulatif final et fusion

  • Le 4 avril 2024, l’auteur a indiqué que toutes les dépendances avaient été traitées et a repassé la PR en état d’être relue
  • p-linnane a fait remarquer que la situation s’était déjà produite et qu’il était donc possible de supprimer les formulations au futur
  • L’auteur a appliqué ce retour et mis à jour la branche avec le commit terraform: deprecate and add caveat 1c7b99b
  • p-linnane, MikeMcQuaid et chenrui333 ont approuvé la modification finale
  • Le 5 avril 2024, la PR a été fusionnée dans le master de Homebrew via la merge queue avec le commit 4782218
  • Le même jour, terraform: deprecate and add caveat #168090 a également été référencée comme PR fusionnée

À lire aussi

1 commentaires

 
GN⁺ 2023-10-09
Avis sur Hacker News

  • Le point important, c’est qu’ils sont en attente afin de voir s’ils peuvent être remplacés par des alternatives, au lieu de supprimer immédiatement les paquets dépendants
    Par exemple, les programmes qui dépendent de Terraform ont de bonnes chances de pouvoir utiliser OpenTofu comme substitut
    Malheureusement, il semble peu probable que des alternatives open source voient le jour pour Vault, Consul et Nomad. Nomad en particulier était un bon produit jusqu’à ce que HashiCorp cesse d’y investir, et maintenant qu’il est devenu à source fermée, il paraît presque comique de penser qu’il puisse encore être adopté

    • Si quelqu’un lançait un fork public de Vault, j’aimerais y contribuer quand j’aurai du temps
      Ajout : https://github.com/hashicorp/vault/graphs/contributors?from=...
    • J’aime beaucoup Nomad. Il est même plus léger que k3s, et il convenait très bien à mes projets à petit budget
      C’est un peu dommage de voir les choses prendre cette tournure
    • Nomad avait une ambition trop large : vouloir tout exécuter. Au final, il ne s’est jamais vraiment imposé, et il fallait aussi Consul pour le configurer
      Docker Swarm est une solution plus simple et meilleure que Nomad, et elle est intégrée directement à Docker Engine
    • Honnêtement, les produits HashiCorp sont globalement très bons. Je pense simplement qu’ils ont souffert du syndrome d’aller trop vite
      Ils ont poussé l’entrée en Bourse, et la plupart des problèmes récents remontent à leurs tentatives de faire monter le cours de l’action
      Les débuts de HashiCorp étaient formidables. C’était un défenseur de l’open source, et l’entreprise ressemblait au prochain Red Hat ou Canonical. Ses produits étaient révolutionnaires et apportaient énormément de valeur à l’écosystème open source. Mais quand Terraform a décollé, cela a aussi attiré l’attention sur les autres produits, et l’entreprise est devenue trop connue
      Depuis l’entrée en Bourse, il est devenu évident qu’ils cherchent à obtenir de l’argent et des clients entreprise à n’importe quel prix
      Terraform lui-même donne l’impression d’être en mode maintenance depuis la version 1. Les providers Terraform cassent souvent, et je pense qu’en production il faut verrouiller les providers jusqu’à la version de patch. Ces dernières années, plusieurs petites mises à jour de patch ont causé des problèmes. HashiCorp est aussi devenu connu pour refuser les contributions open source qui n’ont pas de valeur business pour l’entreprise. Depuis que Terraform a atteint la v1, presque toute l’attention semble s’être portée sur Terraform Cloud et Terraform Enterprise. À HashiConf, toutes les présentations donnent l’impression d’être de la propagande pour pousser ces produits, et on dirait désormais que c’est tout ce qui les intéresse
      Nomad a été pendant un temps un produit sur lequel HashiCorp fondait beaucoup d’espoirs, mais ils semblent l’avoir abandonné en chemin dans leur quête de domination du marché entreprise. Probablement après avoir constaté que la plupart des entreprises avaient tout misé sur Kubernetes et que Nomad était plus utile aux startups qui avancent vite
      Vault était un excellent outil, surtout dans le monde open source. Mais ces dernières années, ils ont fortement séparé la version open source de Vault de la version sous licence, et la version open source a commencé à ressembler à un fardeau pour HashiCorp. L’an dernier, quand mon entreprise a sérieusement envisagé de migrer vers Vault et que nous avons discuté avec HashiCorp, ils ont traité la solution open source auto-hébergée comme une version d’essai du « vrai Vault », et c’est aussi l’impression que cela donnait. Pour presque tous les problèmes rencontrés lors de la configuration, la réponse était du genre : « dans la version Enterprise, ça va »
      Dans l’ensemble, ils se sont retirés en ne gardant que l’effort minimal nécessaire pour prendre en charge les versions open source de leurs produits, et depuis un moment c’est une entreprise entièrement tournée vers les entreprises. Il faut bien gagner de l’argent, donc on ne peut pas seulement les blâmer, mais je ne peux pas m’empêcher de penser à Red Hat et Canonical comme exemples de ce qu’HashiCorp aurait pu devenir
      Aujourd’hui, j’ai l’impression d’être un parent qui voit son enfant ne pas réaliser tout son potentiel. Cela semble surtout dû à la cupidité ou à une ambition excessive. Quand je pense à HashiCorp, la phrase qui me vient est : « je ne suis pas en colère, je suis juste déçu ». J’espère qu’OpenTofu comblera le vide laissé par Terraform. Pour Vault, c’est déjà trop tard : nous utilisons les outils de gestion de secrets des grands fournisseurs cloud. Je les aime beaucoup moins, mais ils sont moins chers et moins complexes. À la place de Nomad, nous utilisons Kubernetes ; comme c’est devenu le standard, ça va. Moi, je m’en sortirai, mais je suis déçu par HashiCorp
    • Nomad est-il vraiment devenu à source fermée ?

  • HashiCorp maintient son propre tap
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

    • À noter que la version possédée par Homebrew les reconstruit depuis les sources : https://github.com/Homebrew/homebrew-core/pull/139538/files#...
      C’est aussi généralement ainsi que fonctionne l’écosystème de packaging Linux, mais celui-ci traite en général explicitement le packaging des dépendances en même temps. C’est peut-être pour cette raison que Vault et les autres n’avaient probablement pas été intégrés aux collections de paquets des distributions, même avant le changement de licence
      La variante côté HashiCorp copie les builds de release : https://github.com/hashicorp/homebrew-tap/blob/master/Formul...

  • Pourquoi ? Homebrew n’est-il pas simplement un gestionnaire de paquets ? Je ne vois pas pourquoi une licence non libre devrait empêcher l’inclusion des outils HashiCorp
    Ou alors existe-t-il une politique selon laquelle seuls les logiciels libres sont inclus ?
    Modification : en fait, il existe des directives assez strictes : https://docs.brew.sh/License-Guidelines

    • Homebrew a pour politique de n’inclure que des logiciels libres [1]
      « Seules les formules utilisant une licence conforme aux Debian Free Software Guidelines, ou publiées dans le domaine public selon les directives du DFSG sur les logiciels du domaine public, sont acceptées dans homebrew/core »
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew n’est pas seulement un simple gestionnaire de paquets
      C’est aussi le logiciel appelé brew, donc un gestionnaire de paquets, mais également le dépôt de paquets homebrew-core auquel il est relié par défaut. Ce dépôt de paquets est géré avec soin et n’accepte que des licences open source
      Vous êtes libre d’utiliser brew pour ajouter le tap du dépôt que vous voulez, mais cette PR ne concerne que le dépôt core
    • Ce n’est qu’en partie exact
      Par défaut, Homebrew prend en charge deux dépôts, homebrew/core et homebrew/casks, autrement dit, dans la terminologie Homebrew, il les « tap »
      Core n’accepte que des logiciels libres, compilés directement par les développeurs de Homebrew et installés notamment dans /opt/homebrew. Casks accepte à peu près tout, y compris les logiciels commerciaux et ceux sans code source. Ces logiciels sont généralement téléchargés directement depuis le développeur et installés à l’emplacement voulu, généralement dans /Applications

  • J’apprécie les services fournis par Homebrew, mais Terraform fait partie des exceptions qu’il vaut mieux gérer en dehors de brew. À l’heure actuelle, tf-switch me semble être l’option la plus populaire
    Avec Terraform, mettre à jour un fichier d’état par erreur peut être risqué, donc il faut souvent verrouiller une version précise. Bien sûr, les mises à jour de Terraform sont devenues beaucoup moins pénibles qu’à l’époque précédant la 1.0

    • J’utilise rtx, c’est-à-dire rust asdf https://github.com/jdx/rtx. Il permet d’installer des langages avec un seul outil, et de gérer aussi des variables d’environnement de projet comme avec direnv
    • Exact. Le mieux est de le gérer dans MacPorts, qui permet d’installer des paquets dans des versions précises et de basculer facilement entre elles
    • Pour installer plusieurs versions de Terraform, on peut aussi utiliser tfenv avec Homebrew

  • Il peut simplement passer en cask à la place. En pratique, l’impact n’est pas très important

    • Oui. Si HashiCorp veut continuer à distribuer via Homebrew, cask suffit tout à fait. Cela dit, ça ne me paraît pas probable. Depuis déjà plusieurs années, ils recommandent d’installer les binaires directement sur les serveurs, et la documentation d’installation de Terraform a fonctionné ainsi pendant un bon moment
      L’impact le plus important concerne les autres outils qui dépendent de Terraform, comme on le voit ici : https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      Des outils comme atlantis et infracost dépendent aussi de Terraform et sont donc en cours de suppression. La distribution de ces petits outils va donc devenir un peu plus difficile. Heureusement, dans ce fil, il est indiqué que la décision est mise en attente afin de pouvoir remplacer la dépendance par une alternative, ou la supprimer complètement, une fois OpenTofu stabilisé. Mais à mon avis, le véritable impact se situe sur ces outils périphériques

  • Homebrew est vraiment utile, mais il comporte aussi des choix de conception étranges. Pourquoi installer un nouveau Python dédié ? Et pourquoi ce Python doit-il être à jour ?
    Or chaque formule doit spécifier une version de Python, si bien qu’en pratique ce n’est pas toujours la plus récente, et on se retrouve avec des formules qui imposent toutes sortes de versions. Je ne comprends pas pourquoi il n’utilise pas le Python système comme les autres gestionnaires de paquets. Il y a déjà trop de Python installés, pas besoin d’en ajouter un de plus. C’est particulièrement déroutant quand il faut installer des paquets pip pour faire fonctionner correctement quelque chose

    • Sans vouloir défendre les choix les plus étranges, utiliser le Python système crée généralement encore plus de problèmes. macOS n’a désormais plus de Python système
      On peut faire comme ceci :
      pythonX.Y -m pip install foo
      Pour éviter toute ambiguïté, on peut aussi utiliser des alias. Pour les projets professionnels, pyenv et les environnements virtuels sont une bonne option

  • Cela ressemble à une décision politique. Il y a beaucoup de paquets dans Homebrew qui ne recevront plus de mises à jour, mais qui ne sont pas dépréciés

    • Une formule qui n’est plus mise à jour parce que l’upstream ne publie plus de nouvelle version, et une formule qui ne peut plus recevoir de nouvelles mises à jour dans Homebrew parce que sa licence n’est plus open source, ce n’est pas la même chose
      La partie de Homebrew qui n’est pas Cask exige une licence open source, et ici on est dans le second cas
    • C’est distinct du fait qu’un paquet soit mort. Les utilisateurs peuvent s’attendre à ce que Homebrew ne produise pas magiquement des mises à jour qui n’existent pas upstream
      En revanche, si des mises à jour existent mais que Homebrew ne peut pas légalement les distribuer, au point que l’utilisateur risque d’installer une version ancienne et vulnérable, cela vaut la peine de l’en avertir
    • Homebrew Core ne contient que des applications sous licences open source, plus précisément des licences compatibles avec les Debian Free Software Guidelines. C’est le cas de GPL, Apache, BSD, MIT, etc.
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...