babushka

Arquivado

Não pretendo fazer mais trabalho em Babushka (na verdade, não o fiz há algum tempo).

Eu tive a ideia e comecei a trabalhar no projeto em 2009. Na época, Docker e até Vagrant ainda não foram concebidos. Em parte, eu queria construir uma alternativa mais simples e em pequena escala a pessoas como chef e fantoche, e em parte começou como um experimento em quão longe eu poderia aprimorar um ruby ​​dsl e até que ponto eu poderia me apoiar nele fazer um trabalho útil. Eu tinha uma bola trabalhando nisso e aprendi muito, e tenho orgulho do fato de que o design inicial provou ser um som. Estou menos orgulhoso de certas partes da implementação - Hoowee escrevia alguns pedaços desse código de maneira diferente hoje - mas então éramos todos jovens uma vez.

Hoje em dia, as coisas são muito diferentes. Com os recipientes modernos e a imutabilidade que eles fornecem, juntamente com ferramentas como Terraform, Kubernetes e assim por diante, Babushka e sua abordagem baseada em mutação são bastante datadas. De fato, exigir um bom e velho Babushka para o trabalho grave de infraestrutura hoje pode ser considerado um tipo de sinal de alerta.

Quanto à criação de um novo laptop e assim por diante, aprendi o longo caminho que um script de shell idiota que copia algumas preferências, executa alguns comandos defaults write e assim por diante, juntamente com algumas etapas manuais, é muito mais fácil de manter. Quanto mais um processo automatizado chega ao macOS, mais rapidamente ficará fora da compatibilidade e, em qualquer caso, a configuração de uma nova máquina é uma ocorrência rara o suficiente para mim que não vale a pena buscar a automação perfeita.

Obrigado a todos que contribuíram e usaram isso ao longo dos anos. Como sempre, se você quiser usá -lo de alguma forma, vá para a sua vida - eu simplesmente não pretendo fazer mais alterações nesse repositório principal. Bem, talvez um dia chuvoso eu refatore os pedaços peludos - veremos.

Saúde e tudo de bom.

---

O que

Babushka é uma ferramenta de comando para automatizar tarefas de computação. Cada parte distinta do trabalho é expressa como uma dependência (DEP), que compreende um teste e o código para fazer esse teste passar.

 dep 'on git branch' , :branch do
  met? {
    current_branch = shell ( 'git branch' ) . split ( " n " ) . collapse ( /^ * / ) . first
    log "Currently on #{ current_branch } ."
    current_branch == branch
  }
  meet {
    log_shell ( "Checking out #{ branch } " , 'git' , 'checkout' , branch )
  }
end

Acima está um DEP expositivo que pode atingir o objetivo modesto de estar no ramo Git correto (observe o parâmetro denotado pelo símbolo: ramificação). Ele foi construído usando as duas palavras DSL met? e meet , que contêm a lógica de cada DEP, separando o teste (a dependência é atendida?) Do código (atenda à dependência).

Executando este dep quando uma troca de ramificação é necessária mostra como o Babushka faz seu trabalho em blocos de Met/Meet/Met: um teste de falha, uma ação realizada cegamente e, em seguida, o mesmo teste novamente, passando agora como resultado.

 $ bin/babushka.rb 'on git branch' branch=stable
on git branch {
  Currently on master.
  meet {
    Checking out stable... done.
  }
  Currently on stable.
} ✓ on git branch

Se já estamos no ramo certo, o teste inicial já está passando e, portanto, não há trabalho a fazer.

 $ bin/babushka.rb 'on git branch' branch=stable
on git branch {
  Currently on stable.
} ✓ on git branch

Tudo isso é muito bem para uma tarefa isolada. Para alcançar algo maior, as tarefas precisam desencadear outras, que é onde a terceira palavra DSL requires .

 dep 'on git branch' , :branch do
  requires 'git'
  # ...

Antes de Babushka processar um DEP na moda Met/Meet/Met descrita acima, todos os seus requisitos são processados ​​até a conclusão da mesma maneira. Isso reflete a realidade: perguntar se estamos na ramificação Git certa nem faz sentido se o Git não estiver instalado.

 $ bin/babushka.rb 'on git branch' branch=stable
on git branch {
  git {
    'git' runs from /usr/bin.
    ✓ git is 2.3.8, which is >= 1.6.
  } ✓ git
  Currently on stable.
} ✓ on git branch

A palavra DSL com complicação requires_when_unmet pode ser usada para especificar dependências necessárias somente quando um determinado dep é considerado não atendido, e isso pode ser ignorado quando o DEP já for atendido. (As ferramentas de construção são um bom exemplo desse requisito.)

Há outras coisas a aprender, como modelos de DEP, fontes dep e as poucas palavras restantes na DSL de Babushka, mas a acima é a noz. Se você amarrar algumas dezenas de depósitos como este, poderá provisionar um servidor do zero ou fazer o que quiser.

Há uma documentação muito mais detalhada no site, juntamente com a documentação por método que pode ser visualizada aqui.

Instalação

Babushka é mais facilmente instalado usando babushka.me/up , um script de shell que instala Babushka via Git (e suas dependências, Ruby e Git, através do gerenciador de pacotes do seu sistema, se necessário). É seguro funcionar nos sistemas existentes e destinado a ser usado como o primeiro comando Shell em um novo sistema também. Você pode instalar Babushka dessa maneira usando curl ou wget :

 sh -c "`curl https://babushka.me/up`"

Se você preferir instalar manualmente, tudo o que você precisa fazer é clonar o repo Git (ou extrair um arquivo dele) e, se quiser, vincule bin/babushka.rb no seu caminho como 'Babushka'.

Verifique a documentação de instalação para obter detalhes sobre a personalização da instalação, incluindo o bloqueio em versões específicas e a instalação de Forks usando babushka.me/up .

Sistemas suportados

O próprio Babushka deve correr em qualquer Unix; Não há nada no núcleo de Babushka que requer outra coisa senão Unix, Ruby e Git.

Eu desenvolvo Babushka no macOS e o uso principalmente no Ubuntu, então o Homebrew e o APT são os gerentes de pacotes mais apoiados. Há também algum apoio YUM (Redhat/Fedora/CentOS) e Pacman (Arch), graças às contribuições de outros. Em outros sistemas, operações específicas (como a instalação de um pacote usando o gerenciador de pacotes desse sistema) falharão com uma mensagem de erro, mas, caso contrário, Babushka deve funcionar bem. De qualquer forma, os patches são bem -vindos.

Agradecimentos

Babushka aproveita essas bibliotecas de rubi:

• Fancypath, de Myles Byrne e Chris Lloyd, para um manuseio de caminho mais conciso nos DEPs;
• Inkan, de Pat Allan, para rastrear alterações nos arquivos renderizados;
• Texto :: Levenshtein, de Paul Battley, para correções de digitação sugeridas.

Muito obrigado a todos que contribuíram para Babushka, enviando patches, discutindo idéias de design comigo, testando ou apenas dando feedback.

Uma lista de colaboradores aqui inevitavelmente fica desatualizada - a página dos colaboradores contém a lista completa. Além disso, o cometimento de versão de versão sempre detalha o que mudou e quem ajudou em suas mensagens de confirmação.

Licença

Babushka é licenciado sob a licença BSD de três cláusulas, exceto lib/levenshtein/levenshtein.rb , que é licenciado sob a licença do MIT.

A licença BSD pode ser encontrada na íntegra no arquivo de licença, e a licença do MIT pode ser encontrada na parte superior da lib/levenshtein/levenshtein.rb .