Homebrew agrega una advertencia sobre HashiCorp y planea deprecarla

 (github.com/Homebrew)
1 puntos por GN⁺ 2023-10-09 | 1 comentarios | Compartir por WhatsApp
  • El PR #139538 de Homebrew/homebrew-core es un cambio que agrega una advertencia al usuario a la formula terraform debido al cambio de licencia de HashiCorp, e informa que podría deshabilitarse en algún momento
  • La razón del cambio es que, después del cambio de licencia, ya no habrá actualizaciones de versión de terraform en homebrew-core, y el enfoque está en que el usuario lo sepa al instalarlo
  • Durante la revisión se discutió una excepción de versión: futuras releases anteriores a 1.6.0 podrían ser aceptables, aunque también existe la posibilidad de que no haya ninguna
  • Tras limpiar las dependencias, el PR volvió a quedar listo para revisión el 4 de abril de 2024 y se actualizó con el commit terraform: deprecate and add caveat, incorporando el feedback de eliminar la redacción en futuro
  • El cambio final se integró a master de Homebrew el 5 de abril de 2024 mediante la merge queue, como el commit 4782218, y también se fusionó el PR relacionado de deprecación de terraform #168090

Deprecación de la formula terraform y agregado de advertencia

  • El objetivo del PR #139538 es informar a los usuarios que, debido al cambio de licencia de HashiCorp, ya no se harán más actualizaciones de versión de terraform en homebrew-core
  • La explicación inicial iba en la dirección de informar al usuario que “esta formula podría deshabilitarse en algún momento”
  • El cambio afectaba a Formula/terraform.rb, y luego la ruta del archivo pasó a mostrarse como Formula/t/terraform.rb
  • El PR recibió etiquetas como formula deprecated, busl-license, go y maintainer feedback

Debate sobre versiones y licencia

  • Durante la revisión surgió la postura de que futuras releases de terraform anteriores a la versión 1.6.0 podrían ser aceptables
    • Sin embargo, también se planteó que quizá no exista ninguna release de ese tipo
  • La descripción del PR toma como base del cambio el hecho de que, tras el cambio de licencia, ya no habrá más actualizaciones de versión en homebrew-core
  • Después, el mensaje del commit expresó la idea de que, como ya no habrá actualizaciones de versión en homebrew-core por el cambio de licencia, esta formula será deshabilitada en algún momento

Flujo de revisión y aplicación de cambios

  • El PR se abrió el 14 de agosto de 2023 y varios maintainers revisaron los cambios en Formula/terraform.rb
  • El 6 de septiembre de 2023 hubo un ping para pedir que se aplicara el feedback de la revisión, y el autor informó que ya lo había incorporado
  • El 7 de septiembre de 2023 MikeMcQuaid aprobó el cambio, pero fue removido de la merge queue por una falla en las comprobaciones de estado
  • El 20 de septiembre de 2023 chenrui333 también aprobó el cambio
  • El 23 de febrero de 2024 el PR fue marcado como draft

Limpieza de dependencias y PR relacionados

  • El 13 de marzo de 2024, el commit cdktf: deprecate hizo referencia a este PR
    • Ese mensaje de commit indicaba que cdktf usa terraform, que pronto será deprecado
    • Se describía como una de las últimas formulas que impedían la deprecación de terraform
    • También se señalaba que cdktf tiene más de 700 descargas mensuales y que, aunque está alojado en el GitHub org de HashiCorp, no se ve afectado por el cambio de licencia BUSL
  • Como PR relacionado, se fusionó cdktf: deprecate #166001
  • El 3 de abril de 2024, atlantis: vendor terraform #167948 hizo referencia a este PR y también fue fusionado

Cierre final y fusión

  • El 4 de abril de 2024 el autor informó que “todas las dependencias ya fueron resueltas, así que ahora sí está bien” y cambió el PR a review ready
  • p-linnane comentó que, como esa situación ya estaba ocurriendo, podía eliminarse la redacción en futuro
  • El autor reflejó ese cambio y actualizó la rama con el commit terraform: deprecate and add caveat 1c7b99b
  • p-linnane, MikeMcQuaid y chenrui333 aprobaron el cambio final
  • El 5 de abril de 2024 el PR se fusionó a master de Homebrew mediante la merge queue como el commit 4782218
  • Ese mismo día también se referencia como PR fusionado terraform: deprecate and add caveat #168090

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-09
Opiniones en Hacker News

  • Es importante que no estén descartando de inmediato los paquetes dependientes, sino que los estén dejando en espera para ver si pueden cambiarse por alternativas.
    Por ejemplo, es muy probable que los programas que dependen de Terraform puedan usar OpenTofu como reemplazo.
    Lamentablemente, no parece que vayan a surgir alternativas open source para Vault, Consul y Nomad. En especial Nomad era un buen producto hasta que HashiCorp dejó de invertir en él; ahora que pasó a ser de código cerrado, parece casi imposible que se adopte, al punto de que resulta hasta gracioso.

    • Si alguien inicia un fork público de Vault, me gustaría contribuir cuando tenga tiempo.
      Agregado: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • Me gusta bastante Nomad. Es incluso más liviano que k3s y encajaba muy bien con mis proyectos de bajo presupuesto.
      Me da un poco de pena ver que las cosas vayan por este camino.
    • La meta de Nomad de ejecutar absolutamente todo era demasiado ambiciosa. Al final no logró establecerse ampliamente y, para configurarlo, también hacía falta Consul.
      Docker Swarm es una solución más simple y mejor que Nomad, y viene integrada en el propio Docker Engine.
    • Honestamente, los productos de HashiCorp en general son realmente buenos. Pero creo que sufrieron el síndrome de moverse demasiado rápido.
      Forzaron la salida a bolsa, y la mayoría de los defectos recientes se pueden rastrear hasta los intentos por subir el precio de la acción.
      La HashiCorp de los primeros tiempos era impresionante. Era una defensora del open source y parecía una Red Hat o Canonical emergente. Sus productos eran revolucionarios y agregaban un valor enorme al ecosistema open source. Pero cuando Terraform despegó con fuerza, también atrajo atención hacia los demás productos, y la empresa se volvió demasiado conocida.
      Después de salir a bolsa, quedó claro que buscaban dinero y clientes empresariales a cualquier costo.
      Terraform en sí también se siente como si estuviera en modo mantenimiento desde la versión 1. Los Terraform providers se rompen con frecuencia, y creo que en producción hay que fijar los providers incluso hasta la versión de parche. En los últimos años hubo varios problemas incluso con pequeñas actualizaciones de parche. También se hicieron conocidos por empezar a rechazar contribuciones open source que no tuvieran valor comercial para HashiCorp. Desde que Terraform llegó a v1, casi toda la atención parece haberse ido a Terraform Cloud y Terraform Enterprise. En HashiConf, todas las charlas se sienten como propaganda para impulsar esos productos, y ahora parece que solo les importa eso.
      Nomad fue durante un tiempo un producto en el que HashiCorp tenía muchas expectativas, pero parece que lo dejaron tirado en la cuneta mientras perseguían dominar el mercado empresarial. Probablemente fue después de darse cuenta de que la mayoría de las empresas apostaron todo a Kubernetes y de que Nomad era más útil para startups que se mueven rápido.
      Vault era una herramienta excelente, especialmente en el ámbito open source. Pero en los últimos años separaron mucho la versión open source de Vault de las versiones con licencia, y la versión open source empezó a sentirse como una carga para HashiCorp. El año pasado, cuando en mi empresa evaluamos seriamente migrar a Vault y hablamos con HashiCorp, trataron la solución open source autohospedada como si fuera una versión de prueba del “Vault de verdad”, y en la práctica también se sentía así. Para casi todos los problemas que encontramos durante la configuración, la respuesta era algo como “en la versión Enterprise eso está bien”.
      En general, se replegaron hasta dejar solo el esfuerzo mínimo necesario para dar soporte a las versiones open source de sus productos, y desde hace un tiempo son una empresa completamente enfocada en el mercado empresarial. Tienen que ganar dinero, así que no se los puede culpar sin más, pero no puedo evitar pensar en Red Hat y Canonical como ejemplos de lo que HashiCorp podría haber llegado a ser.
      Ahora me siento como un padre que ve que su hijo no llegó a desplegar todo su potencial. En gran parte parece deberse a la codicia o a una ambición excesiva. Cuando pienso en HashiCorp, me viene a la mente la frase: “no estoy enojado, solo decepcionado”. Espero que OpenTofu llene el vacío que dejó Terraform. Vault ya quedó atrás para nosotros y estamos usando herramientas de gestión de secretos de los grandes proveedores cloud. Me gustan mucho menos, pero son más baratas y menos complejas. En lugar de Nomad usamos Kubernetes, y como de todos modos ya se volvió el estándar, está bien. Yo voy a estar bien, pero HashiCorp me decepcionó.
    • ¿Nomad realmente pasó a ser de código cerrado?

  • HashiCorp mantiene su propio tap.
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

  • ¿Por qué? ¿Homebrew no es simplemente un gestor de paquetes? No entiendo por qué una licencia no libre debería limitar la inclusión de herramientas de HashiCorp
    ¿O acaso tiene una política de incluir solo software libre?
    Edición: en realidad tiene lineamientos bastante estrictos: https://docs.brew.sh/License-Guidelines

    • Homebrew tiene una política de incluir solo software libre [1]
      “Solo se aceptan en homebrew/core fórmulas que usen licencias de las Debian Free Software Guidelines, o que hayan sido publicadas como dominio público según los lineamientos de software de dominio público de la DFSG”
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew no es solo un gestor de paquetes
      Es el software llamado brew, es decir, un gestor de paquetes, pero también el repositorio de paquetes homebrew-core que viene conectado por defecto. Ese repositorio de paquetes se administra cuidadosamente y solo acepta licencias open source
      Eres libre de usar brew para hacer tap de cualquier repositorio que quieras, pero este PR trata solo del repositorio core
    • Esto es solo parcialmente correcto
      Por defecto, Homebrew admite —o, en términos de Homebrew, hace tap de— dos repositorios: homebrew/core y homebrew/casks
      Core solo acepta software libre, lo compilan directamente los desarrolladores de Homebrew y se instala en ubicaciones como /opt/homebrew. Casks acepta casi cualquier cosa, incluido software comercial y software sin código fuente. Ese software normalmente se descarga directamente desde el desarrollador y se instala donde corresponda, por lo general en /Applications

  • Me gustan los servicios que ofrece Homebrew, pero Terraform es uno de esos casos excepcionales que conviene gestionar fuera de brew. Hoy diría que tf-switch es la opción más popular
    Con Terraform a menudo hay que fijar una versión concreta, porque actualizar accidentalmente un archivo de estado puede ser peligroso. Claro que las actualizaciones de Terraform son mucho menos problemáticas que en la época anterior a la 1.0

    • Yo uso rtx, es decir, rust asdf https://github.com/jdx/rtx. Permite instalar lenguajes con una sola herramienta y también manejar variables de entorno de proyecto, como direnv
    • Exacto. Lo mejor es gestionarlo dentro de MacPorts, donde se pueden instalar paquetes de versiones específicas y cambiar entre ellas fácilmente
    • Para instalar varias versiones de Terraform, también se puede usar tfenv desde Homebrew

  • En su lugar puede ir en cask. En la práctica no tiene mucho impacto

    • Sí. Si HashiCorp quiere seguir distribuyendo vía Homebrew, hacerlo como cask es perfectamente posible. Aunque no creo que vaya a pasar. Desde hace años ya vienen recomendando instalar los binarios directamente desde sus servidores, y la documentación de instalación de Terraform también estuvo así durante un tiempo
      El impacto mayor está en otras herramientas que dependen de Terraform, como se ve aquí: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      Herramientas como atlantis e infracost también dependen de Terraform y se están eliminando. Así que la distribución de esas herramientas más pequeñas se volverá un poco más difícil. Por suerte, en ese hilo dicen que lo dejarán en espera para que, cuando OpenTofu se estabilice, puedan cambiar la dependencia por el reemplazo o eliminarla por completo. Pero creo que el impacto real está en esas herramientas periféricas

  • Homebrew es muy útil, pero también tiene decisiones de diseño raras. ¿Por qué instala un Python nuevo dedicado? ¿Y por qué ese Python tiene que ser el más reciente?
    Pero como cada formula tiene que especificar una versión de Python, en la práctica ni siquiera siempre termina siendo la última, y aparecen formulas que especifican todo tipo de versiones. No entiendo por qué no usa el Python del sistema como otros gestores de paquetes. Ya hay demasiados Python instalados; no necesito uno más. Es especialmente confuso cuando hay que instalar paquetes con pip para que algo funcione bien

    • No voy a defender hasta las decisiones más raras, pero usar el Python del sistema suele traer más problemas. macOS ya no tiene Python del sistema
      Puedes usarlo así:
      pythonX.Y -m pip install foo
      Para eliminar ambigüedades, también puedes usar alias. Para proyectos de trabajo conviene usar pyenv y entornos virtuales

  • Parece una decisión política. En Homebrew hay muchos paquetes que ya no reciben actualizaciones, pero no se descartan

    • Una cosa es una formula que no se actualiza porque upstream no publica versiones nuevas, y otra es una formula que no puede recibir nuevas actualizaciones en Homebrew porque su licencia ya no es open source
      La parte de Homebrew que no es Cask exige una licencia open source, y este caso es lo segundo
    • Es distinto a que el paquete esté muerto. Los usuarios pueden esperar que Homebrew no fabrique mágicamente actualizaciones que no existen upstream
      En cambio, si las actualizaciones sí existen pero Homebrew no puede distribuirlas legalmente, y eso podría llevar a instalar una versión vieja y vulnerable, vale la pena advertir al usuario
    • Homebrew Core solo incluye apps con licencias open source, específicamente licencias compatibles con las Debian Free Software Guidelines. GPL, Apache, BSD, MIT, etc. entran en esa categoría
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...