Homebrew adiciona alerta sobre a HashiCorp e prevê descontinuação

 (github.com/Homebrew)
1 pontos por GN⁺ 2023-10-09 | 1 comentários | Compartilhar no WhatsApp
  • O PR #139538 de Homebrew/homebrew-core é uma alteração que adiciona um aviso ao usuário na formula terraform por causa da mudança de licença da HashiCorp e informa que ela poderá ser desativada em algum momento
  • O motivo da mudança é que, após a alteração de licença, o terraform não terá mais atualizações de versão no homebrew-core, com foco em garantir que o usuário saiba disso ao instalar
  • Durante a revisão, foi discutida uma exceção de versão: futuras releases anteriores à 1.6.0 poderiam ser aceitáveis, embora também possa não haver nenhuma release desse tipo
  • Após a limpeza de dependências, o PR voltou a ficar pronto para revisão em 4 de abril de 2024 e foi atualizado com o commit terraform: deprecate and add caveat, incorporando o feedback para remover formulações no tempo futuro
  • A alteração final foi mesclada ao master do Homebrew em 5 de abril de 2024 pela merge queue como o commit 4782218, e o PR relacionado de descontinuação do terraform, #168090, também foi mesclado

Descontinuação da formula terraform e adição de aviso

  • O objetivo do PR #139538 é informar aos usuários que, devido à mudança de licença da HashiCorp, o homebrew-core não terá mais atualizações de versão do terraform
  • A descrição inicial seguia a linha de informar aos usuários que “esta formula poderá ser desativada em algum momento”
  • O alvo da mudança era Formula/terraform.rb, e depois o caminho do arquivo passou a aparecer como Formula/t/terraform.rb
  • O PR recebeu labels como formula deprecated, busl-license, go e maintainer feedback

Discussão sobre versões e licença

  • Durante a revisão, surgiu a opinião de que, entre futuras releases do terraform, versões anteriores à 1.6.0 poderiam ser aceitáveis
    • No entanto, também foi apontada a possibilidade de que tais releases simplesmente não existam
  • A descrição do PR usou como base para a mudança o fato de que, após a alteração de licença, não haveria mais atualizações de versão no homebrew-core
  • Depois, a mensagem de commit passou a expressar a ideia de que “por causa da mudança de licença, não há mais atualizações de versão no homebrew-core, então esta formula será desativada em algum momento”

Fluxo de revisão e incorporação das mudanças

  • O PR foi aberto em 14 de agosto de 2023, e vários maintainers revisaram a alteração em Formula/terraform.rb
  • Em 6 de setembro de 2023, houve um ping solicitando a incorporação do feedback de revisão, e o autor informou que ela havia sido concluída
  • Em 7 de setembro de 2023, MikeMcQuaid aprovou a alteração, mas ela foi removida da merge queue por falha nas verificações de status
  • Em 20 de setembro de 2023, chenrui333 também aprovou a alteração
  • Em 23 de fevereiro de 2024, o PR foi marcado como draft

Limpeza de dependências e PRs relacionados

  • Em 13 de março de 2024, o commit cdktf: deprecate referenciou este PR
    • A mensagem desse commit afirma que cdktf usa o terraform, que será descontinuado em breve
    • Ela o descreve como uma das últimas formulas que impediam a descontinuação do terraform
    • Também diz que o cdktf tem mais de 700 downloads por mês e, embora esteja hospedado na organização da HashiCorp no GitHub, não é afetado pela mudança de licença para BUSL
  • Como PR relacionado, cdktf: deprecate #166001 foi mesclado
  • Em 3 de abril de 2024, atlantis: vendor terraform #167948 referenciou este PR e foi mesclado

Ajustes finais e merge

  • Em 4 de abril de 2024, o autor informou que “todas as dependências foram tratadas, então agora está tudo certo” e mudou o PR para pronto para revisão
  • p-linnane deu o feedback de que, como a situação já havia acontecido, as expressões no tempo futuro poderiam ser removidas
  • O autor incorporou isso e atualizou o branch com o commit terraform: deprecate and add caveat 1c7b99b
  • p-linnane, MikeMcQuaid e chenrui333 aprovaram a alteração final
  • Em 5 de abril de 2024, o PR foi mesclado ao master do Homebrew pela merge queue no commit 4782218
  • No mesmo dia, terraform: deprecate and add caveat #168090 também foi referenciado como um PR mesclado

Leituras relacionadas

1 comentários

 
GN⁺ 2023-10-09
Opiniões no Hacker News

  • É importante notar que os pacotes dependentes não estão sendo descontinuados imediatamente; estão em espera para ver se podem ser trocados por alternativas
    Por exemplo, programas que dependem do Terraform têm boa chance de poder usar o OpenTofu como substituto
    Infelizmente, não parece que vá surgir uma alternativa open source para Vault, Consul e Nomad. Especialmente o Nomad era um bom produto até a HashiCorp parar de investir nele; agora que virou código fechado, chega a ser engraçado, porque parece muito improvável que seja adotado

    • Se alguém iniciar um fork público do Vault, eu gostaria de contribuir quando tiver tempo
      Adição: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • Gosto bastante do Nomad. Ele é ainda mais leve que o k3s e serviu muito bem para meus projetos de baixo orçamento
      É um pouco triste ver as coisas seguirem esse rumo
    • O objetivo do Nomad de executar absolutamente tudo era ambicioso demais. No fim, ele não se consolidou amplamente, e para configurá-lo também era preciso usar Consul
      O Docker Swarm é uma solução mais simples e melhor que o Nomad, e vem embutido no próprio Docker Engine
    • Sinceramente, os produtos da HashiCorp são, no geral, muito bons. Só acho que a empresa sofreu da síndrome de se mover rápido demais
      Ela forçou a abertura de capital, e a maioria das falhas recentes pode ser rastreada até tentativas de elevar o preço das ações
      A HashiCorp no início era incrível. Era uma defensora do open source e parecia uma Red Hat ou Canonical em ascensão. Seus produtos eram revolucionários e agregavam um valor enorme ao ecossistema open source. Mas, quando o Terraform explodiu, ele também chamou atenção para os outros produtos, e a empresa ficou famosa demais
      Depois do IPO, ficou claro que a prioridade passou a ser conseguir dinheiro e clientes corporativos a qualquer custo
      O próprio Terraform também parece estar em modo de manutenção desde a versão 1. Os providers do Terraform quebram com frequência e, em ambientes de produção, acho que é preciso fixar os providers até a versão de patch. Nos últimos anos, houve problemas várias vezes até em pequenas atualizações de patch. A empresa também ficou conhecida por começar a recusar contribuições open source que não tinham valor comercial para a HashiCorp. Desde que o Terraform chegou ao v1, quase toda a atenção parece ter ido para o Terraform Cloud e o Terraform Enterprise. Na HashiConf, todas as apresentações parecem propaganda empurrando esses produtos, e agora parece que é só isso que importa
      O Nomad foi, por um tempo, um produto no qual a HashiCorp apostava muito, mas parece ter sido deixado de lado no caminho da busca pelo domínio do mercado corporativo. Provavelmente depois que perceberam que a maioria das empresas apostou tudo em Kubernetes e que o Nomad era mais útil para startups de movimentação rápida
      O Vault era uma ferramenta excelente, especialmente no mundo open source. Mas, nos últimos anos, eles separaram bastante a versão open source do Vault da versão licenciada, e a versão open source começou a parecer um fardo para a HashiCorp. No ano passado, quando minha empresa avaliou seriamente migrar para o Vault e conversou com a HashiCorp, eles trataram a solução open source self-hosted como se fosse uma versão de avaliação do “Vault de verdade”, e foi exatamente essa a sensação. Para quase todo problema que encontramos na configuração, a resposta era algo como “na versão Enterprise isso funciona bem”
      No geral, eles recuaram até deixar apenas o esforço mínimo necessário para dar suporte às versões open source dos produtos, e há um bom tempo são uma empresa totalmente focada em clientes corporativos. Não dá para só condenar, já que precisam ganhar dinheiro, mas não consigo deixar de pensar na Red Hat e na Canonical como exemplos do que a HashiCorp poderia ter se tornado
      Hoje me sinto como um pai vendo o filho não alcançar todo o seu potencial. Parece ter sido, em grande parte, por ganância ou ambição excessiva. Quando penso na HashiCorp, me vem à cabeça a frase “não estou bravo, só decepcionado”. Espero que o OpenTofu preencha o vazio deixado pelo Terraform. O Vault já ficou para trás para nós, e agora usamos a ferramenta de gerenciamento de segredos de um grande provedor de nuvem. Gosto bem menos dela, mas é mais barata e menos complexa. No lugar do Nomad, usamos Kubernetes; como ele virou o padrão, está tudo bem. Eu vou ficar bem, mas estou decepcionado com a HashiCorp
    • O Nomad virou mesmo código fechado?

  • A HashiCorp mantém seu próprio tap
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

  • Por quê? O Homebrew não é apenas um gerenciador de pacotes? Não entendo por que uma licença não livre deveria limitar a inclusão de ferramentas da HashiCorp
    Ou será que existe uma política de incluir apenas software livre?
    Edit: na verdade há diretrizes bem rigorosas: https://docs.brew.sh/License-Guidelines

    • O Homebrew tem uma política de incluir apenas software livre [1]
      “Aceitamos no homebrew/core apenas formulas que usem uma licença das Debian Free Software Guidelines, ou que tenham sido lançadas em domínio público de acordo com as diretrizes da DFSG para software em domínio público”
      [1]: https://docs.brew.sh/License-Guidelines
    • O Homebrew não é apenas um simples gerenciador de pacotes
      Ele é o software chamado brew, ou seja, o gerenciador de pacotes, mas também o repositório de pacotes homebrew-core vinculado por padrão. Esse repositório de pacotes é gerenciado com cuidado e só aceita licenças open source
      Você é livre para usar o brew para dar tap no repositório que quiser, mas este PR trata apenas do repositório core
    • Isso está só parcialmente correto
      Por padrão, o Homebrew dá suporte a dois repositórios, homebrew/core e homebrew/casks — ou, na terminologia do Homebrew, faz tap neles
      O Core só aceita software livre, é compilado diretamente pelos desenvolvedores do Homebrew e é instalado em locais como /opt/homebrew. Já o Casks aceita praticamente qualquer coisa, incluindo software comercial e software sem código-fonte. Esse tipo de software normalmente é baixado diretamente do lado do desenvolvedor e instalado no local desejado, geralmente em /Applications

  • Gosto do serviço que o Homebrew oferece, mas o Terraform é um daqueles casos excepcionais em que é melhor gerenciar fora do brew. Hoje, acho que o tf-switch é a opção mais popular
    Com o Terraform, muitas vezes é preciso fixar uma versão específica, porque atualizar acidentalmente o arquivo de estado pode ser arriscado. Claro que também é verdade que atualizar o Terraform ficou muito menos trabalhoso do que era antes da versão 1.0

    • Eu uso o rtx, isto é, o asdf em Rust https://github.com/jdx/rtx. Dá para instalar linguagens com uma única ferramenta e também lidar com variáveis de ambiente de projeto, como no direnv
    • Exato. O melhor é gerenciar dentro do MacPorts, que permite instalar pacotes em versões específicas e alternar facilmente entre elas
    • Para instalar várias versões do Terraform, o tfenv também pode ser usado via Homebrew

  • Em vez disso, pode entrar no cask. Na prática, não tem muito impacto

    • Sim. Se a HashiCorp quiser continuar distribuindo via Homebrew, dá perfeitamente para fazer por cask. Mas não acho que isso vá acontecer. Nos últimos anos, eles já vinham recomendando instalar os binários diretamente a partir do servidor, e a documentação de instalação do Terraform também seguiu esse método por um tempo
      O impacto maior é sobre outras ferramentas que dependem do Terraform, como dá para ver aqui: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      Ferramentas como atlantis e infracost também dependem do Terraform e estão sendo removidas. Então a distribuição dessas ferramentas menores ficará um pouco mais difícil. Felizmente, nesse thread dizem que vão deixar em espera até o OpenTofu estabilizar, para que a dependência possa ser trocada pelo substituto ou removida por completo. Mas acho que o impacto real está nessas ferramentas ao redor

  • O Homebrew é realmente útil, mas também tem escolhas de design estranhas. Por que instalar um Python dedicado novo? E por que esse Python precisa ser o mais recente?
    Só que, como cada formula precisa especificar uma versão de Python, na prática ele nem sempre fica na versão mais recente, e acabam surgindo formulas especificando todo tipo de versão. Não entendo por que ele não usa o Python do sistema, como outros gerenciadores de pacotes. Já há Pythons instalados demais; não preciso de mais um. Isso fica especialmente confuso quando é preciso instalar pacotes pip para fazer algo funcionar direito

    • Não estou tentando defender até as escolhas mais estranhas, mas usar o Python do sistema normalmente causa mais problemas. O macOS agora nem tem mais Python do sistema
      Use assim:
      pythonX.Y -m pip install foo
      Para eliminar a ambiguidade, você também pode usar um alias. Para projetos de trabalho, é bom usar pyenv e ambientes virtuais

  • Parece uma decisão política. Há muitos pacotes no Homebrew que não receberão mais atualizações, mas não são descontinuados

    • Há diferença entre uma formula que não é atualizada porque o upstream não lança novas versões e uma formula que não pode receber novas atualizações no Homebrew porque a licença deixou de ser open source
      A parte do Homebrew que não é Cask exige licença open source, e este caso é o segundo
    • Isso é separado do fato de o pacote estar morto. O usuário pode esperar que o Homebrew não crie magicamente atualizações que não existem no upstream
      Por outro lado, se as atualizações existem, mas o Homebrew não pode distribuí-las legalmente, e isso pode levar à instalação de uma versão antiga e vulnerável, vale a pena avisar o usuário
    • O Homebrew Core só inclui apps com licenças open source, mais especificamente licenças compatíveis com as Debian Free Software Guidelines. Isso inclui GPL, Apache, BSD, MIT etc.
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...