Homebrew fügt Warnung zu HashiCorp hinzu und plant Deprecation

 (github.com/Homebrew)
1 Punkte von GN⁺ 2023-10-09 | 1 Kommentare | Auf WhatsApp teilen
  • Homebrew/homebrew-core PR #139538 ist eine Änderung, die wegen der Lizenzänderung von HashiCorp eine Benutzerwarnung zur terraform-Formula hinzufügt und darauf hinweist, dass sie eines Tages deaktiviert werden könnte
  • Grund für die Änderung ist, dass es nach der Lizenzänderung in homebrew-core keine Versionsupdates für terraform mehr geben wird; der Fokus liegt darauf, Nutzer bei der Installation darauf aufmerksam zu machen
  • Im Review-Prozess wurde eine Versionsausnahme diskutiert: Künftige Releases vor 1.6.0 könnten akzeptabel sein, allerdings wurde auch angemerkt, dass es solche Releases möglicherweise gar nicht geben wird
  • Nach dem Aufräumen von Abhängigkeiten war der PR am 4. April 2024 wieder reviewbereit und wurde unter Berücksichtigung des Feedbacks, Formulierungen im Futur zu entfernen, mit dem Commit terraform: deprecate and add caveat aktualisiert
  • Die finale Änderung wurde am 5. April 2024 über die Merge Queue in Homebrew master als Commit 4782218 gemergt; auch der zugehörige terraform-Deprecation-PR #168090 wurde gemergt

Deprecation der terraform-Formula und Hinzufügen einer Warnung

  • Ziel von PR #139538 ist es, Nutzer darüber zu informieren, dass es wegen der Lizenzänderung von HashiCorp in homebrew-core keine Versionsupdates für terraform mehr gibt
  • Die ursprüngliche Beschreibung zielte darauf ab, Nutzer darauf hinzuweisen, dass „diese Formula eines Tages deaktiviert werden könnte“
  • Geändert wurde Formula/terraform.rb; später wurde der Dateipfad als Formula/t/terraform.rb angezeigt
  • Der PR erhielt Labels wie formula deprecated, busl-license, go und maintainer feedback

Diskussion zu Versionen und Lizenz

  • Während des Reviews wurde die Ansicht geäußert, dass von künftigen terraform-Releases Versionen vor 1.6.0 akzeptabel sein könnten
    • Gleichzeitig wurde jedoch darauf hingewiesen, dass es solche Releases möglicherweise gar nicht geben wird
  • Die PR-Beschreibung begründet die Änderung damit, dass es nach der Lizenzänderung in homebrew-core keine weiteren Versionsupdates mehr gibt
  • Spätere Commit-Messages enthielten sinngemäß, dass man diese Formula eines Tages deaktivieren werde, da es wegen der Lizenzänderung in homebrew-core keine Versionsupdates mehr gebe

Review und Übernahme der Änderungen

  • Der PR wurde am 14. August 2023 eröffnet, und mehrere Maintainer reviewten die Änderung an Formula/terraform.rb
  • Am 6. September 2023 gab es einen Ping mit der Bitte, Review-Feedback einzuarbeiten; der Autor meldete anschließend die Umsetzung
  • Am 7. September 2023 genehmigte MikeMcQuaid die Änderung, sie wurde jedoch wegen fehlgeschlagener Statusprüfungen aus der Merge Queue entfernt
  • Am 20. September 2023 genehmigte auch chenrui333 die Änderung
  • Am 23. Februar 2024 wurde der PR als Draft markiert

Aufräumen von Abhängigkeiten und zugehörige PRs

  • Am 13. März 2024 referenzierte der Commit cdktf: deprecate diesen PR
    • Die Commit-Message erklärte, dass cdktf das demnächst deprecated terraform verwendet
    • Sie beschrieb dies als eine der letzten Formulas, die die Deprecation von terraform blockierten
    • Außerdem hieß es, cdktf werde mehr als 700-mal pro Monat heruntergeladen und sei trotz Hosting in der HashiCorp-GitHub-Org nicht von der BUSL-Lizenzänderung betroffen
  • Als zugehöriger PR wurde cdktf: deprecate #166001 gemergt
  • Am 3. April 2024 referenzierte atlantis: vendor terraform #167948 diesen PR und wurde gemergt

Finale Bereinigung und Merge

  • Am 4. April 2024 teilte der Autor mit, dass „alle Abhängigkeiten behandelt“ seien und es nun in Ordnung sei, und stellte den PR auf review ready
  • p-linnane gab das Feedback, dass Formulierungen im Futur entfernt werden könnten, da die Situation bereits eingetreten sei
  • Der Autor übernahm dies und aktualisierte den Branch mit dem Commit terraform: deprecate and add caveat 1c7b99b
  • p-linnane, MikeMcQuaid und chenrui333 genehmigten die finale Änderung
  • Am 5. April 2024 wurde der PR über die Merge Queue als Commit 4782218 in Homebrew master gemergt
  • Am selben Tag wurde auch terraform: deprecate and add caveat #168090 als gemergter PR referenziert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-09
Meinungen auf Hacker News

  • Wichtig ist, dass abhängige Pakete nicht sofort verworfen werden, sondern vorerst zurückgestellt sind, um zu sehen, ob man sie durch Alternativen ersetzen kann
    Programme, die zum Beispiel von Terraform abhängen, könnten wahrscheinlich OpenTofu als Ersatz verwenden
    Leider ist bei Vault, Consul und Nomad kaum damit zu rechnen, dass Open-Source-Alternativen entstehen. Besonders Nomad war ein gutes Produkt, bis HashiCorp die Investitionen einstellte; jetzt, da es Closed Source ist, wirkt es fast schon absurd, weil es kaum noch Chancen auf Adoption zu haben scheint

    • Wenn jemand einen öffentlichen Fork von Vault startet, würde ich gern beitragen, sobald ich Zeit habe
      Nachtrag: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • Ich mag Nomad ziemlich. Es ist sogar leichtergewichtig als k3s und passte sehr gut zu meinen Low-Budget-Projekten
      Es ist etwas schade zu sehen, dass es sich so entwickelt
    • Nomad hatte das viel zu ambitionierte Ziel, alles auf der Welt ausführen zu wollen. Am Ende konnte es sich nicht breit etablieren, und zum Einrichten brauchte man auch noch Consul
      Docker Swarm ist eine einfachere und bessere Lösung als Nomad und ist direkt in Docker Engine integriert
    • Ehrlich gesagt sind HashiCorp-Produkte insgesamt wirklich gut. Ich denke nur, sie litten am Syndrom, sich zu schnell zu bewegen
      Der Börsengang wurde vorangetrieben, und die meisten der jüngsten Schwächen lassen sich auf Versuche zurückführen, den Aktienkurs zu steigern
      Das frühe HashiCorp war großartig. Es war ein Hüter von Open Source und wirkte wie ein aufstrebendes Red Hat oder Canonical. Die Produkte waren bahnbrechend und brachten dem Open-Source-Ökosystem enormen Wert. Doch als Terraform groß wurde, zog das auch Aufmerksamkeit auf die anderen Produkte, und das Unternehmen wurde zu bekannt
      Nach dem Börsengang wurde klar, dass es nun um Geld und Unternehmenskunden um jeden Preis ging
      Terraform selbst fühlt sich seit Version 1 ebenfalls wie im Wartungsmodus an. Terraform-Provider gehen häufig kaputt, und in Produktionsumgebungen sollte man Provider meiner Meinung nach bis auf Patch-Versionen festpinnen. In den letzten Jahren gab es selbst bei kleinen Patch-Updates mehrfach Probleme. HashiCorp ist auch dafür bekannt geworden, Open-Source-Beiträge abzulehnen, die für das Unternehmen keinen geschäftlichen Wert haben. Seit Terraform v1 erreicht hat, scheint fast die gesamte Aufmerksamkeit Terraform Cloud und Terraform Enterprise zu gelten. Auf der HashiConf fühlt sich jeder Vortrag wie Werbung an, die diese Produkte pusht, und inzwischen scheint es nur noch darum zu gehen
      Nomad war eine Zeit lang ein Produkt, in das HashiCorp große Hoffnungen setzte, aber auf dem Weg zur Eroberung des Enterprise-Markts scheint es am Straßenrand liegen gelassen worden zu sein. Vermutlich nachdem klar wurde, dass die meisten Unternehmen komplett auf Kubernetes setzen und Nomad eher für schnell agierende Startups nützlich ist
      Vault war ein hervorragendes Tool, besonders im Open-Source-Bereich. In den letzten Jahren wurden die Open-Source-Version und die lizenzierte Version von Vault jedoch stark auseinanderdividiert, und die Open-Source-Version begann sich für HashiCorp wie eine Last anzufühlen. Als wir letztes Jahr im Unternehmen ernsthaft einen Wechsel zu Vault prüften und mit HashiCorp sprachen, behandelten sie die Open-Source-Self-Hosting-Lösung wie eine Testversion von „echtem Vault“, und genauso fühlte es sich auch an. Auf fast jedes Problem, das uns bei der Einrichtung begegnete, hieß es sinngemäß: „In der Enterprise-Version ist das in Ordnung“
      Insgesamt hat man sich darauf zurückgezogen, nur noch den minimal nötigen Aufwand zu betreiben, um die Open-Source-Versionen der Produkte zu unterstützen, und HashiCorp ist schon seit einiger Zeit ein vollständig auf Unternehmen ausgerichtetes Unternehmen. Man kann ihnen nicht nur Vorwürfe machen, weil sie Geld verdienen müssen, aber ich muss unweigerlich an Red Hat und Canonical als Beispiele dafür denken, was HashiCorp hätte werden können
      Heute fühlt es sich an wie bei Eltern, die zusehen, wie ihr Kind sein Potenzial nicht ausschöpft. Es scheint größtenteils an Gier oder übertriebenem Ehrgeiz zu liegen. Wenn ich an HashiCorp denke, kommt mir der Satz „Ich bin nicht wütend, nur enttäuscht“ in den Sinn. Ich hoffe, dass OpenTofu die Lücke füllt, die Terraform hinterlässt. Vault ist für uns schon vorbei; wir nutzen jetzt das Secret-Management-Tool eines großen Cloud-Anbieters. Es gefällt mir deutlich weniger, ist aber günstiger und weniger komplex. Statt Nomad verwenden wir Kubernetes, und da es ohnehin zum Standard geworden ist, ist das okay. Mir wird es gut gehen, aber von HashiCorp bin ich enttäuscht
    • Ist Nomad wirklich Closed Source geworden?

  • HashiCorp pflegt einen eigenen Tap
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

  • Warum ist das so? Ist Homebrew nicht einfach nur ein Paketmanager? Ich verstehe nicht, warum eine unfreie Lizenz die Aufnahme von HashiCorp-Tools einschränken sollte
    Oder gibt es eine Richtlinie, dass nur freie Software aufgenommen wird?
    Korrektur: Tatsächlich gibt es ziemlich strenge Richtlinien: https://docs.brew.sh/License-Guidelines

    • Homebrew hat die Richtlinie, nur freie Software aufzunehmen [1]
      „In homebrew/core werden nur Formulae akzeptiert, die eine Lizenz nach den Debian Free Software Guidelines verwenden oder gemäß den DFSG-Richtlinien für Public-Domain-Software als Public Domain veröffentlicht wurden“
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew ist nicht nur ein einfacher Paketmanager
      Es ist sowohl die Software brew, also der Paketmanager, als auch das standardmäßig angebundene Paket-Repository homebrew-core. Dieses Paket-Repository wird sorgfältig gepflegt und akzeptiert nur Open-Source-Lizenzen
      Es steht einem frei, beliebige Repositories mit brew zu tappen, aber dieser PR betrifft nur das Core-Repository
    • Das stimmt nur teilweise
      Standardmäßig unterstützt Homebrew die beiden Repositories homebrew/core und homebrew/casks, in Homebrew-Terminologie also Taps
      Core akzeptiert nur freie Software, wird von Homebrew-Entwicklern selbst gebaut und unter anderem in /opt/homebrew installiert. Casks akzeptiert nahezu alles, auch kommerzielle Software und Software ohne Quellcode. Solche Software wird in der Regel direkt vom Entwickler heruntergeladen und an den gewünschten Ort installiert, normalerweise nach /Applications

  • Ich schätze den Dienst, den Homebrew bietet, aber Terraform ist einer der Ausnahmefälle, die man besser außerhalb von brew verwalten sollte. Im Moment halte ich tf-switch für die beliebteste Wahl
    Bei Terraform muss man oft eine bestimmte Version festpinnen, weil es riskant sein kann, versehentlich die State-Datei zu aktualisieren. Natürlich stimmt es, dass Terraform-Updates deutlich weniger mühsam geworden sind als in der Zeit vor 1.0

    • Ich nutze rtx, also rust asdf https://github.com/jdx/rtx. Damit kann man Sprachen mit einem Tool installieren und auch Projekt-Umgebungsvariablen wie mit direnv verwalten
    • Genau. Am besten ist es, das in MacPorts zu verwalten, wo man Pakete in bestimmten Versionen installieren und einfach wechseln kann
    • Um mehrere Terraform-Versionen zu installieren, kann man auch tfenv über Homebrew nutzen

  • Stattdessen kann es in cask aufgenommen werden. Praktisch hat das keine besonders große Auswirkung

    • Genau. Wenn HashiCorp weiterhin über Homebrew ausliefern will, wäre das auch über cask ohne Weiteres möglich. Allerdings glaube ich nicht, dass das passieren wird. Schon in den letzten Jahren wurde empfohlen, Binaries direkt von den Servern zu installieren, und die Terraform-Installationsdokumentation ging eine Zeit lang ebenfalls in diese Richtung
      Die größere Auswirkung betrifft, wie man hier sieht, andere Tools, die von Terraform abhängen: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      Auch Tools wie atlantis und infracost hängen von Terraform ab und werden deshalb entfernt. Dadurch wird die Distribution solcher kleineren Tools etwas schwieriger werden. Glücklicherweise heißt es in diesem Thread, dass man abwartet, damit die Abhängigkeit auf einen Ersatz umgestellt oder ganz entfernt werden kann, sobald OpenTofu stabil ist. Die tatsächlichen Auswirkungen sehe ich aber bei solchen peripheren Tools

  • Homebrew ist wirklich nützlich, hat aber auch seltsame Designentscheidungen. Warum wird ein eigenes neues Python installiert? Und warum muss dieses Python die neueste Version sein?
    Da aber jede Formula die Python-Version angeben muss, ist es in der Praxis gar nicht immer die neueste, und es entstehen Formulae, die alle möglichen Versionen festlegen. Ich verstehe nicht, warum nicht wie bei anderen Paketmanagern das System-Python verwendet wird. Es sind ohnehin schon zu viele Pythons installiert; ich brauche nicht noch eins. Besonders verwirrend wird es, wenn man pip-Pakete installieren muss, damit irgendetwas richtig funktioniert

    • Ich will nicht jede noch so seltsame Entscheidung verteidigen, aber die Verwendung von System-Python führt normalerweise zu mehr Problemen. Auf macOS gibt es inzwischen kein System-Python mehr
      So geht es:
      pythonX.Y -m pip install foo
      Um Mehrdeutigkeit zu vermeiden, kann man auch Aliasse verwenden. Für Arbeitsprojekte sind pyenv und virtuelle Umgebungen sinnvoll

  • Das wirkt wie eine politische Entscheidung. In Homebrew gibt es viele Pakete, die keine Updates mehr bekommen, aber nicht deprecated werden

    • Es ist ein Unterschied zwischen einer Formula, die nicht aktualisiert wird, weil Upstream keine neue Version veröffentlicht, und einer Formula, die keine neuen Updates mehr über Homebrew erhalten kann, weil die Lizenz nicht mehr Open Source ist
      Der Nicht-Cask-Teil von Homebrew verlangt Open-Source-Lizenzen, und dieser Fall gehört zur zweiten Kategorie
    • Das ist etwas anderes als ein totes Paket. Nutzer können erwarten, dass Homebrew nicht auf magische Weise Updates erstellt, die es Upstream nicht gibt
      Wenn dagegen Updates existieren, Homebrew sie aber rechtlich nicht verteilen darf und man dadurch womöglich eine alte, verwundbare Version installiert, ist eine Warnung für Nutzer sinnvoll
    • In Homebrew Core kommen nur Apps mit Open-Source-Lizenzen, genauer gesagt mit Lizenzen, die mit den Debian Free Software Guidelines kompatibel sind. Dazu gehören GPL, Apache, BSD, MIT usw.
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...