Como Fazer Squash de Commits no Git

Tradução livre de Squash Commits with Git, disponível em http://davidwalsh.name/squash-commits-git/.

Não sou um expert de git, mas sei o suficiente para me virar bem, e com certeza sei o suficiente sobre git para gostar mais dele do que do svn. Um tempo atrás publiquei sobre alguns comandos básicos de git, ensinando como ir além do básico dos clones e commits, passando pela maioria das interações que o git fornece. A mini-lição de hoje envolve fazer o squash de múltiplos commits em um só, facilitando a revisão de pull requests e ajudando com a gestão de merges.

Comece fazendo alterações no feature branch onde você vai trabalhar. Vamos supor que essas alterações são alguns commits que eu quero consolidar num único. O primeiro passo consiste em garantir que o branch master está sincronizado com o branch master do repositório destino:

# entre no branch master
git checkout master

# garanta que seu repositório está atualizado
git pull nomeRepositorioRemoto master

Com o branch master sincronizado, usamos o git rebase para fazer a consolidação:

git rebase -i master

Esse comando mostra uma lista de commits, dessa forma:

pick fb554f5 This is commit 1
pick 2bd1903 This is commit 2
pick d987ebf This is commit 3

# Rebase 9cbc329..d987ebf onto 9cbc329
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Edite o sumário mostrado pelo comando rebase, deixando o commit que você quer deixar principal como “pick”, e alterando todos os comandos “pick” subsequentes por “squash”:

pick fb554f5 This is commit 1
squash 2bd1903 This is commit 2
squash d987ebf This is commit 3

# Rebase 9cbc329..d987ebf onto 9cbc329
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Salve o conteúdo e feche o editor duas vezes (a segunda tela permite que você altere a mensagem de commit, apesar de eu preferir manter sempre a mesma mensagem). Nesse momento, seus commits serão aglutinados em um só: é o squash! Execute o seguinte comando para forçar o push desse commit novo e consolidado.

# Force um push
git push -f

Esse push forçado atualiza o repositório fonte, e nossos commits são transformados em um só. Se você já tinha mandado um pull request no GitHub com esse conteúdo, agora o PR vai aparecer como um único commit! E, com um commit consolidado, a revisão do código se torna muito, mas muito, mais fácil!

É isso aí, pessoal, até mais!

#30contribs – Cheguei nos 30! E quero de presente Pull Requests e contribuições para projetos open source e da comunidade!

Olá!

Hoje, dia 24 de junho de 2015 é um dia especial, pelo menos para mim :-) : cheguei nos 30! E como é meu aniversário, quero pedir um presente. Na verdade, um monte de presentes!!!

#30contribs 

Eu quero ver muitos Pull Requests e contribuições para projetos open source e da comunidade!

#30contribs

Minha ideia surgiu do projeto http://24pullrequests.com/ que, sempre no fim de cada ano, incentiva a ajuda para projetos open source. E também do saudoso Sou PHPSP e Contribuo, que em 2011 fez bastante gente começar nesse mundo das contribuições! E também de uma ideia que eu tive (mas não tinha colocado em prática) na apresentação que fiz no TDC 2014: Becoming a Contributor, Open Sourcer and Beyond.

O #30contribs não tem um site específico (ainda 😉 ) e nem a ideia de distribuir prêmios com base nas contribuições. É só contribuir! E colocar a hashtag #30contribs !

Mande o máximo que você puder! Só consegue uma contribuição? Tudo bem! Consegue várias? Melhor ainda! Não consegue nenhuma, mas vai correr atrás para conseguir daqui a pouco? Maravilha!

Ah, se quiser me mencionar (não precisa, mas ia ser bem legal), sou o @rogeriopradoj em quase todo lugar. Então, é só escrever, depois do texto do seu commit (ou pull request, ou issue, ou mensagem no Twitter, ou no Facebook etc):

“Essa contribuição é um presente #30contribs para o @rogeriopradoj”.

Ou algo assim!

E onde eu posso contribuir?

Se você já costuma contribuir para algum projeto, continue! Mantenha essa boa prática!

Se você tem algum projeto que sempre quis contribuir, mas ainda não tinha dado o primeiro passo, que tal começar agora com esse empurrãozinho?

Ou se você ainda não tem ideia nenhuma, não deixe que algum medo ou “vergonha” do seu código te impeça de começar! Tenho certeza que você se surpreenderá quando começar a contribuir. Tem sempre espaço para mais ajuda, mesmo pequenas contribuições são válidas! Além disso, a maioria do pessoal está disposta a ajudar quem está começando!

Quero sugestões de onde posso começar a contribuir!

Quer ajuda para saber por onde começar? Posso sugerir alguns lugares que conheço!

Que tal os projetos do PHPSP? Hoje, sou um dos evangelistas desse grupo e ajudo a organizar alguns eventos da comunidade. Tem uma série de projetos que precisam de ajuda sob o chapéu do grupo, então acesse lá: https://github.com/PHPSP. Ah, todos são bem-vindos a fazer parte do PHPSP!

E que tal o Saia de Casa!? Projeto que comecei com o William Espindola há alguns anos, o Saia de Casa! é uma agenda colaborativa de eventos para desenvolvedores mantida por desenvolvedores! Acesse lá: https://github.com/saiadecasa/saiadecasa.github.io

E que tal o #VagrantSP ou o https://github.com/FriendsOfVagrant? Muitos sabem que sou um entusiasta da ferramenta Vagrant já faz tempo!. O FriendsOfVagrant foi onde comecei a contribuir com a documentação em português no passado. Agitar um grupo de usuários em São Paulo era questão de tempo, foi aí que foi criado o Meetup Vagrant-Sao-Paulo (valeu Paulo Rezende por me apoiar também nessa empreitada)! Quer ajudar no GitHub: https://github.com/FriendsOfVagranthttps://github.com/vagrantsp/

E que tal o PHP-Build? Um projeto muito bacana de um austríaco (o Christoph Hochstrasser, @CHH), que serve para compilar o PHP em várias versões diferentes, em paralelo, na mesma máquina! Funciona muito bem em Linux, e também no Mac OS X. E até no Windows, se você usar algo como Vagrant ou Docker! Não conhece o PHP-Build e quer usar? Sugiro: https://php-build.github.io/https://github.com/rogeriopradoj/phpenv-installer http://rogeriopradoj.com/2012/11/20/como-atualizar-a-versao-do-php-no-mac-osx-mountain-lion/. Para ajudar nos repositórios: https://github.com/php-buildhttps://github.com/php-build/php-build/wiki/phpenv%20tools.

E que tal me ajudar em alguns pacotes PHP e FrontEnd/JavaScript que estão disponíveis no Packagist e no Bower? Acessa lá: https://packagist.org/packages/rogeriopradoj/http://bower.io/search/?q=rogeriopradoj.

Caramba, já sugeri aí em cima um monte de projetos, e tem mais um monte que gostaria de colocar! Se quiser mais ideias, dêem uma olhada no meu GitHub: https://github.com/rogeriopradoj.

Mas, de novo, essas são apenas sugestões, então, não importa para onde: o mais importante é que você faça mais contribuições!

Para não esquecer, #30contribs 

É isso aí, #30contribs ! Precisando de ajuda, é só chamar!

E feliz aniversário! :-)

Este artigo foi publicado originalmente em RogerioPradoJ.com.

 

 

Como acompanhar as listas de discussão oficiais do PHP.net

Olá, pessoal,

Hoje vamos falar sobre as listas de discussões oficiais do PHP, as famosas mailing lists do PHP.net (só como adendo, PHP.net é o site da linguagem que hospeda também muitos projetos relacionados, como os conhecidos PEAR.php.net e PECL.php.net, o repositório GIT.php.net, até o muitas vezes desconhecido PEOPLE.php.net. Para conhecer mais, use a WIKI.php.net).

Para que servem as mailing lists?

As listas de discussão são onde conseguimos ter as informações mais recentes, interessantes muitas vezes, e provavelmente inéditas sobre vários assuntos.

É bem possível se manter bem informado sobre o andamento do ecossistema PHP por uma série de lugares: sites e blogs especializados, livros, encontros de comunidades (já conhece o PHPSP? :-) :-) :-) )…  O próprio GitHub (php/php-src) é uma ótima fonte de informação hoje em dia. Mas, sem  acompanhar as listas de discussão, perde-se um pouco do potencial que temos à nossa disposição.

Você já deve ter escutado algo do tipo:

…O pessoal no Internals está discutindo chamar a próxima versão da linguagem de XYZ, mas Joãozinho não aceitou por causa disso e daquilo outro…

No começo deve ter ficado “boiando”, e perguntou o que era aquele Internals, descobrindo que era uma mailing list/lista de discussão. Mas só saber o nome da lista não adianta muito, se você não conseguir assiná-la, não é mesmo?

Eu tive problema parecido. Foi quando estava começando a buscar mais informações sobre como trabalhar na tradução do manual do PHP para pt-BR, no PHPSP+Docs #1 de 11/2013. O fera Klaus Silveira me indicou o caminho descrito na wiki dos esforços da tradução, que era assim:

…Toda a comunicação entre os tradutores deve ser feita através da lista de email oficial… (doc-pt-br@lists.php.net)

Ok, já tinha até o “nome completo” da lista, mas ainda não sabia como assiná-la! Por que será que era tão difícil?!?!

Um pouco diferente do que fazemos Yahoo e Google Groups

Lembro que na época da faculdade era comum participar de listas de distribuição internas dos grupos da sala. As primeiras, feitas no Yahoo Grupos, e com o tempo, as coisas começando a migrar para o Google Groups. Hoje ainda participo de uma série por lá, como o PHP Brasil Comunidades e o php-build developers, e nunca tive dificuldade para assinar nenhuma das listas. O passo era:

  • criar uma conta Yahoo/Google
  • acessar o site do grupo
  • clicar no botão registrar/assinar/entrar
  • e ser feliz!

Além do mais a lista nesses casos sempre tinha uma página web específica, onde quem não tinha assinado podia ver online as discussões, e quem já estava cadastrado podia editar suas opções de recebimento (quantidade de e-mails diários a receber, descadastramento etc.). E o pior que esse fluxo funcionava para qualquer lista! E, com certeza, esse foi o problema!

Numa palestra que assisti sobre Agile, ministrada pelo Juan Bernabó, da Germinadora, ele dizia que aprender era fácil quando conseguimos desaprender antes, o que é difícil. Eu demorei muito mais para achar o formato de assinatura para as mailing lists do PHP.net porque eu demorei para “desaprender” o jeito Yahoo/Google. E não é que o jeito PHP.net é fácil também! Só é diferente! Vamos lá então ver como fazer.

Interface web das listas de discussão

Primeiro você tem que achar qual é a lista de seu interesse. Em http://news.php.net/ estão listadas todas as opções. É só clicar sobre o link referente à lista que você escolher e navegar por ela. Bem simples.

PHP mailing lists news.php.net

Quer umas dicas para começar?

Passos para assinar uma lista de discussão PHP.net

Assinar listas principais com botão Subscribe

Você pode acessar a página http://php.net/mailing-lists.php que te dá uma introdução sobre o funcionamento das listas, mostra as principais delas (o índice completo está em http://news.php.net/), e permite que se assine por lá.

http://php.net/mailing-lists.php

 

Exemplo de assinatura da lista Internals:

http://php.net/mailing-lists.php

  1. acesse http://php.net/mailing-lists.php
  2. selecione/marque o radio button Normal em Internal List
  3. digite seu e-mail no campo Email
  4. clique no botão Subscribe

Pronto. No fim, você vai receber um e-mail automático, para confirmar a assinatura é só responder a mensagem.

confirm_subscribe_to_internals_lists_php_net

 

Assinar listas sem botão de Subscribe

Infelizmente, nem todas as listas estão lá naquele endereço, e é necessário trabalhar um pouquinho mais para começar a receber as discussões em sua caixa postal. Mas não é nada impossível, existem comandos que permitem gerenciar suas assinaturas sem nem precisar de interface web. E, o melhor, funcionam para qualquer tipo, tanto as principais quanto as outras.

O sistema de listas de distribuição que o PHP.net utiliza é o ezmlm-idx, cujo manual de utilização está disponível no endereço http://untroubled.org/ezmlm/ezman/ezman1.html. Então, se quiser ir mais a fundo, é só RTFM! Mas é lógico que vou colocar aqui os comandos mais básicos e úteis para o nosso caso.

Para ver todos os possíveis comandos sobre uma lista, é só mandar um e-mail para:

nomedalista-help@lists.php.net

Percebeu ali o -help (hífen help) antes da arroba (@)? Se você souber o nome da lista (sugiro usar como base o http://news.php.net/ para pegar o nome), é só mandar um email para lá (não precisa ter assunto nem corpo de texto) que você receberá de volta as instruções.

Agora, para assinar uma lista, é o -subscribe (hífen subscribe) que você usará:

nomedalista-subscribe@lists.php.net

E, para cancelar a assinatura, -unsubscribe (hífen unsubscribe):

nomedalista-unsubscribe@lists.php.net

Como nos inscreveríamos então na lista doc-pt-br, onde rolam as discussões sobre a tradução para português (pt-BR) do manual da linguagem?

É só mandar um e-mail para:

doc-pt-br-subscribe@lists.php.net

E se quisesse cancelar a assinatura?

E-mail para doc-pt-br-unsubscribe@lists.php.net.

Quer mais informações: http://php.net/manual/en/faq.mailinglist.php

Considerações finais

As listas de discussão oficiais, as famosas mailing lists do PHP.net são um ótimo lugar para acompanhar informação privilegiada e muitas vezes passam despercebidas por muitos desenvolvedores. Nesse artigo aprendemos a localizá-las, acessá-las via interface web, e também a como assiná-las para recebimento no seu próprio e-mail.

Foquei bastante na lista doc-pt-br, pois a tradução de documentações é um dos meus maiores focos no mundo open source. A tradução do manual do PHP para português é um projeto que estou bastante envolvido no momento, que precisa de bastante ajuda da comunidade.

Se quiser saber mais, pode acessar a lista, a wiki e também ficar de olho em #PHPTranslationFestBrasil2014 no Twitter e nesta issue do PHPSP, que mais novidades serão divulgadas por lá!

Como sempre, fiquem à  vontade para perguntar e discutir nos comentários, ou em qualquer lugar da internet, sou o @RogerioPradoJ.

Até mais!

Referências

Este artigo foi publicado originalmente em RogerioPradoJ.com.

 

 

Testando rapidamente projetos PHP, ou com Vagrant, ou com Docker ou com Servidor Web embutido

Olá, pessoal!

Dica rápida para quem quiser testar algum projeto PHP usando o Vagrant, ou o Docker, ou o Servidor Web embutido no PHP.

Vagrant

Já conhece o https://phpagrant.github.io/ ? Nada mais é do que uma lista de sites geradores de Vagrantfile (e tudo o mais que você precisa de provisionadores) para seu projeto PHP com base no Vagrant.

Phpagrant_github_io_by_PHPagrant

Tem para todos os gostos: Puppet, Chef, Ansible. Você escolhe! Acesse lá, https://phpagrant.github.io/!

Docker

O novo “queridinho” do mundo da virtualização e conteinerização, o Docker, está evoluindo rápido e é importante você correr atrás do prejuízo e aprender sobre ele.

Docker_-_Build__Ship__and_Run_Any_App__Anywhere

Até a versão 1.2.x tinha um sério problema para os usuários de sistemas não Linux: o Boot2Docker, camada VM para permitir que usuários de OS X e Windows usem o Docker, não permitia usar pastas compartilhadas por padrão. Alguns hacks foram lançados (como o ótimo artigo do Chris Jones) , mas depois do lançamento da versão 1.3.0, tudo ficou mais fácil: foi embutido suporte para pastas compartilhadas e está mais simples para quem não usa Linux como máquina principal de desenvolvimento ter o Docker como parte do seu processo de trabalho.

Mas e sobre o PHP? Vamos lá! Algumas imagens disponíveis no https://registry.hub.docker.com/ para você se divertir:

  • oficialhttps://registry.hub.docker.com/_/php/ (falta FPM, mas já tem CLI e Apache com mod_php)

  • @brunoric: https://hub.docker.com/u/brunoric/ (brasileiro, aqui de São Paulo, especialista no Docker. Tem uma série de imagens PHP, vários sabores, até HHVM)

Além disso, seguindo a issue https://github.com/codeguy/php-the-right-way/pull/453, dá para ver que em pouco tempo o PHP: The Right Way (e o PHP: Do Jeito Certo) terá conteúdo sobre Docker e PHP (hoje eles já tem conteúdo sobre Vagrant).

Para quem quer ir direto colocar a mão na massa, o que estou fazendo:

  • Primeiro instalei o Docker (e, como estou num OS X, o Boot2Docker também. Comando para garantir que ele está ligado: boot2docker up)

  • [OS X apenas:] coloquei no meu ‘/etc/hosts’ o hostname ‘localdocker’ apontando para o IP 192.168.59.103 (esse ip é o que comando boot2docker ip mostra). Isso só é necessário para quem usa boot2docker, pois o Docker de verdade está rodando dentro de uma VM, com esse IP aí de cima. Quem está rodando no Windows deve ser algo parecido. Quem está rodando no Linux, não tem que se preocupar com isso, pois o Docker está usando o IP da sua máquina de verdade.

– Vou na pasta que seria o document root da minha aplicação (onde tem o front controller, geralmente index.php) . Como estou no OS X, essa pasta tem que estar dentro de /Users para usar o compartilhamento de pasta automático do boot2docker 1.3+. Ex:

$ cd /Users/eu/projetos/php123/

  • De lá, rodo o seguinte comando:

$ docker run --name my-php-webserver -p 8080:80 -v `pwd`:/var/www/html/ php:apache

O que aconteceu por trás do comando DOCKER RUN:

  • cria e já executa um container, baseado na imagem php versão apache

  • habilita o volume/disco internamente (dentro do container) como /var/www/html/ e externamente (na máquina host/vm boot2docker) como o resultado comando pwd (diretório atual)

  • redireciona a porta 80 interna (no container) para a porta 8080 externa (na máquina host)

É isso!

Quando precisar desligar o container, fazer os seguintes comandos:

  • $ docker ps -a (e copiar o CONTAINER ID)

  • $ docker rm CONTAINER_ID_QUE_VOCÊ_ACHOU_NO_COMANDO_ANTERIOR

Servidor embutido

Vai ter momentos que você não quer ou não pode ir para um dos modelos acima, Vagrant ou Docker. E nem quer instalar um servidor web completo (Apache, Nginx etc.) na sua máquina de desenvolvimento. O que fazer?

Se você tem o PHP CLI já instalado, é bom saber que desde a versão 5.4 é possível usar o servidor web embutido. Leia mais na documentação oficial.

PHP__Built-in_web_server_-_Manual

Então, na pasta onde seria o document root da sua aplicação PHP (onde ter o front controller, certo?), digite o seguinte comando:

$ php -S localhost:8899

A porta ali, no caso 8899, poderia ser qualquer uma de sua preferência. E você já tem um servidor web rodando servindo seu código PHP, no seu navegador disponível em http://localhost:8899. Fácil, não? Você ainda pode configurar algo como um .htaccess, a Lorna Jane Mitchell tem um artigo de 2012 falando do assunto. Mas, de novo, leia a doc oficial que você tem muita informação lá.

Considerações finais

Hoje você não é mais obrigado a instalar um servidor web como o Apache ou o Nginx apenas para testar uma aplicação PHP básica. O Servidor web embutido, desde o PHP 5.4 (março de 2012), fornece a estrutura básica para que, em desenvolvimento, você tenha um servidor mínimo.

Caso você precise espelhar o servidor de produção (hardware, sistema operacional e softwares utilizados), vá para o Vagrant, que te entrega isso de forma fácil com a virtualização, tanto para projetos genéricos quanto para projetos PHP.

E, se quiser estar na crista do onda, aplicando conteinerização também no ambiente de desenvolvimento, teste o Docker com PHP.

E fique a vontade de usar os comentários se quiser ajuda!

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Pra não dizer que não falei de Vagrant

Esse post é uma republicação do artigo no site do PHPSP (http://phpsp.org.br/index.php/pra-nao-dizer-que-nao-falei-de-vagrant/).

Olá, pessoal.

Vagrant logo

Vamos falar um pouco dessa ferramenta super útil que promete (e cumpre) ser a revolução para ambientes de desenvolvimento virtualizados, o Vagrant! Mas antes de falar da ferramenta em si, é importante começar com o seguinte: como é hoje o seu ambiente de desenvolvimento?

Evolução do ambiente de desenvolvimento

Vou contar um pouco da evolução do meu ambiente de desenvolvimento, talvez faça você recordar de algo que provavelmente já ocorreu com você:

– Sem noção, altero tudo em produção

– Separação do ambiente, instalo tudo na minha máquina

– Minha máquina vira uma carroça, e tudo dá conflito

– Leio o texto do Anderson (Duodraco) Casimiro, aprendo que é uma boa virtualizar o ambiente de desenvolvimento dentro de uma máquina virtual, que posso ligar e desligar a qualquer momento

– Virtualização dá trabalho!

Virtualização, promessa

A VM permite deixar os ambientes:

– leves

– reproduzíveis

– portatéis

Virtualização, os 3 pilares

– Hardware

– Sistema operacional

– Softwares

Automatizando os 3 pilares da Virtualização, aqui que entra o Vagrant

Vagrantfile: é a cola

Boxes: são VMs base, que já tem o Hardware e o Sistema Operacional definidos

Provisionamento: são os scripts que automatizam a instalação e configuração dos Softwares

Como começar

– Leia o artigo do Duodraco, http://duodra.co/2012/02/18/desenvolvimento-php-usando-maquinas-virtuais-fastcgi-fpm/, e fique bravo se não funcionar com você (é o que aconteceu comigo 😉 )

– Baixa o instalador do Vagrant e leia a documentação no site oficial, http://www.vagrantup.com/ (existe um trabalho para traduzir a documentação para português, se quiser dê uma olhada em http://friendsofvagrant.github.io/, contribuições são bem-vindas)

– Conheça as Boxes oficiais e as criadas pelas comunidade em http://www.vagrantbox.es/, várias diferentes distribuições de Linux

– Comece com módulos e cookbooks para provisionamento prontos e ajuste para o que precisa (o Vagrant suporta muitos mais, no entanto o Puppet (https://forge.puppetlabs.com/) e o Chef são os mais conhecidos (http://community.opscode.com/)

– Importante!!!: Procure aprender mais sobre Gerência de Configuração e Provisionamento, vão ser uma mão na roda para você

Aprofunde-se

Depois que você tiver passado por esses passos, já entender o mínimo do conceito e tiver colocado pelo menos um pouquinho a mão na massa, aí compensa você ir para coisas mais avançadas, seguindo a própria documentação do Vagrant e o monte de informação disponível na web (minha dica, procure pelos plugins para Vagrant https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins).

Me ajude mais!!!

E para facilitar bastante o seu desenvolvimento, duas ferramentas que já criam o esqueleto completo para você: Vagrantfile + Box + Provisionamento! São o mundo perfeito para realmente começar um projeto do zero sem ter quase nenhum trabalho nesse nível:

– http://rove.io/, dica do Elton Minetto, cria tudo para você baseado no provisionador Chef. Bom para projetos Ruby ou PHP/LAMP

– https://puphpet.com/ , cria tudo para você, com muito mais opções de configuração, baseado no provisionador Puppet. Muito bom para projetos PHP, tanto sobre Apache como sobre Nginx.

Puphpet logo
Logo do Puphpet

É isso aí pessoal, material não falta, não é mesmo?!?!

Já tivemos até o primeiro evento de Vagrant no Brasil, fiquem atentos para os próximos.

Se quiser aproveitar para ajudar em um projeto que tem tudo a ver com o tema, e é feito em PHP, deêm uma olhada no Github do projeto Puphpet, vocês vão ajudar muita gente com isso, e se envolver em um projeto Open Source é sempre bacana.

Bom divertimento, e qualquer coisa, me procurem, estou em todo lugar como rogeriopradoj!

Como usar o Vagrant.has_plugin? no Vagrantfile

Olá, pessoal!

Esse artigo é uma continuação do Vagrant e seus plugins, de outubro de 2013, e, para falar a verdade, começou a ser escrito antes do original. É que percebi que, sem uma explicação mais básica do que eram os plugins, ia “faltar base” – como dizia um professor do cursinho!. Então, mais uma vez, se quiser primeiro saber o que são os plugins no Vagrant, leia o artigo original primeiro, ok?

vagrant-has-plugin

O que é o método Vagrant.has_plugin?

O has_plugin? é um método da API do Vagrant, para ser usado no seu Vagrantfile, que verifica se um plugin está disponível no sistema. Com o grande número de plugins disponíveis (confira os listados na wiki oficial), é importante ter uma forma de garantir que quem for usar seu projeto Vagrant tenha os plugins que você definiu/utilizou, e, se não tiver, fazer algo com essa informação.

Vamos ver um exemplo para deixar mais fácil o entendimento:

Nesse trecho acima vemos um Vagrantfile que utiliza o plugin vagrant-cachier para acelerar o vagrant up se o usuário tem o plugin instalado na máquina, e, caso não tenha, tudo continua funcionando, apenas sem a aceleração. Sem usar o has_plugin? o Vagrant interromperia o processo com uma mensagem de erro.

Parece bastante com o conceito de progressive enhancement/graceful degradation: forneça ao usuário que tem apenas o requisito básico uma versão funcional do seu projeto, sem traumas. E, para os que tem mais requisitos (no caso o plugin que definimos), entregue também as funções melhoradas (nesse caso, uma camada de cache que vai acelerar o provisionamento das máquinas virtuais. Se você ainda não conhece o vagrant-cachier, do brasileiro Fabio Rehm, ou @fgrehm, é uma boa hora de começar!).

Um outro exemplo segue abaixo:

Nesse caso, ao contrário do anterior, é feita uma ação quando um plugin não existe no sistema. E quando que isso é útil? Principalmente para os casos que onde precisamos avisar para o usuário que um plugin é necessário/recomendável para executar a aplicação, dando algum caminho para que ele possa resolver a situação. No exemplo acima, avisamos que o projeto está usando o plugin vagrant-bindler para fazer a gestão dos plugins e passamos um caminho para que o usuário faça a instalação do mesmo se ele ainda não tiver (plugin também criado pelo @fgrehm).

Há tempos… um problema!

A função Vagrant.has_plugin? foi introduzida no Vagrant na versão 1.3.0, com alguns problemas, e na versão 1.3.2 foi realmente consertada, isso tudo em setembro de 2013. Mas por que então, mesmo tendo uma certa idade, essa função ainda não é tão utilizada?

Isso acontece por uma pequena inconsistência na implementação dessa API, que faz com que o nome do plugin internamente para o Vagrant (que vai ser usada na chamada Vagrant.has_plugin?) seja diferente do nome do plugin que é usado na instalação via linha de comando $ vagrant plugin install ....

Antes de perceber isso acima, eu mesmo no começo não conseguia entender a lógica, que parecia ser tão simples: fazer uma condição ruby IF ou UNLESS, passando o nome do plugin. Por que não funcionava? Era essa bendita inconsistência de nomes. Ainda bem que não desisti de entender!

Para facilitar, vamos chamar esses nomes da seguinte forma:

  • nome de instalação do plugin: usado no comando $ vagrant plugin install ....
  • nome interno do plugin: usado no Vagrantfile, com o método has_plugin?

Com isso em mente, vamos para os  exemplos:

Quando acessamos a lista oficial dos plugins disponíveis para Vagrant lá não encontramos o nome interno (ainda, estou trabalhando nisso :-) ); apenas aparece o nome de instalação. Uma diferença que, às vezes, é apenas de maíusculas ou minúsculas entre os nomes das duas versões mas que já atrapalha tudo!

Peguemos o Bindler. Para instalá-lo no sistema, é usado o nome da Gem (em minúsculas):

$ vagrant plugin install bindler

Já para usar no seu Vagrantfile, com o has_plugin?, tem que ser o nome interno do plugin (começando com maíscula):

Vagrant.has_plugin?("Bindler")

É, realmente é complicado. Por não haver um padrão, é possível encontrar todos os tipos de combinações: nomes iguais, totalmente diferentes ou apenas a diferença de capitulares. Mas existe uma solução! Vamos vê-la?

A solução!

E a solução é: aprender a ler o repositório do plugin! Puxa, não é o que você estava esperando, não é mesmo… É, por enquanto (dezembro de 2013), não existe uma solução perfeita, por isso vamos aprender aqui a ler o repositório sempre que você precisar.

Arquivos importantes

O primeiro passo é saber localizar, dentro de um repositório, o nome de instalação do plugin e o nome interno do plugin:

  • /nome-de-instalação-do-plugin.gemspec: é nesse arquivo que temos o nome de instalação. O arquivo fica na pasta raiz do repositório do plugin. Exemplos: bindler.gemspec, vagrant-aws.gemspec, vagrant-cachier.gemspec etc.
  • /lib/nome-de-instalação-do-plugin/plugin.rb: é nesse arquivo que temos o nome interno. O arquivo fica no terceiro nível do repositório do plugin. Dentro desse arquivo, existe um atributo name, que é o nome interno que você vai usar. Exemplos para os mesmos plugins acima: BindlerAWSvagrant-cachier.

Achar o repositório do plugin

O segundo passo é saber onde está o repositório do plugin. Minha sugestão, comece pela lista oficial, e siga o link de lá. Na maioria das vezes, você vai cair num repositório no GitHub (ou em algum outro serviço de hospedagem de projetos open source).

A partir daí é só navegar buscando os arquivos mostrados ali em cima, que você já terá a informação necessária para trabalhar.

Considerações finais

Vimos que o Vagrant.has_plugin? é um método da API do Vagrant muito útil para utilizar nos seus projetos. Principalmente importante para os projetos compartilhados com muitas pessoas, verificando em tempo de execução a existência ou não de um plugin determinado, permitindo que quem tenha o plugin aproveite as funcionalidades, mas não impedindo que os usuários sem o plugin tenham uma experiência pelo menos básica.

Entendemos também que existem dois nomes para os plugins: o nome de instalação e o nome interno, e qual deles deve ser usado junto com o Vagrant.has_plugin?. Aprendemos quando usar cada um deles, e como descobrir o nome lendo o repositório do plugin (fique de olho na wiki da lista oficial de plugins, pois vou fazer um trabalho visando facilitar a pesquisa centralizada desses nomes, seria interessante, certo?).

Quer uma dica de plugins para começar a trabalhar? Dê uma olhada no meu artigo original, Vagrant e seus plugins, que tem algumas opções que já utilizo. Agora é sua vez de montar uma estratégia de uso dos plugins e do has_plugin? nos seus projetos Vagrant e

Fique à vontade para tirar suas dúvidas nos comentários (ou me procure, estou em quase todo lugar na internet como rogeriopradoj, é só chamar!)

Feliz vagrant up!

Referências:

[1] https://github.com/fgrehm/bindler/issues/22

[2] https://gist.github.com/rogeriopradoj/6954261

[3] https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins

 

Vagrant e seus plugins

E lá vamos nós falar de Vagrant!

vagrant-e-seus-plugins

Resumo da história dos plugins no Vagrant

Os plugins viraram cidadões de primeira classe na API v2 do Vagrant (antes eles até eram suportados com um pouco de mágica e um monte de requires no meio do seu Vagrantfile). Agora, como o Mitchell Hashimoto diz, o próprio Vagrant usa a API de plugins interna para boa parte de suas implementações, por isso, é possível ficar mais tranquilo de que as coisas funcionarão e que a interface é estável e bem suportada.

Não tenho nenhum plugin ainda desenvolvido, mas já utilizo vários para facilitar meu trabalho com o Vagrant. Então, vamos conhecer um pouco mais?

Como instalar plugins no Vagrant

A documentação do Vagrant sobre plugins está bem completa nesse ponto, e é bem fácil: nada mais do que rodar: $ vagrant plugin install NOME-DO-PLUGIN.

Exemplo para instalar o vagrant-aws:

$ vagrant plugin install vagrant-aws.

Os plugins são na maioria mantidos pela comunidade, e por isso não existe uma listagem oficial. No entanto, existe uma página na wiki do projeto com os plugins marcados pelos usuários, sugiro que visite para buscar os que sirvam para o seu caso de uso.

Quer uma dica de alguns para começar? Veja abaixo:

Plugins Vagrant que não podem faltar para mim

Bindler

Para quem conhece o Composer no mundo PHP, o Bundler no mundo Ruby ou o Bower no mundo FrontEnd, é fácil entender o que esse plugin faz e também a vantagem de usá-lo, o Bindler.

Ele permite que você crie um arquivo na raiz do seu projeto Vagrant (na mesma pasta onde você coloca o seu Vagrantfile) para distribuição, deixando claro para seus usuários que plugins são as suas dependências.

Quando alguém for usar o seu projeto, executará $ vagrant plugin bundle antes do $ vagrant up, e o Bindler se encarregará de instalar as dependências que faltarem. Se o usuário já tiver os plugins instalado globalmente, estes serão usados, senão, o Bindler instalará o que faltar localmente para o projeto apenas. E quando o usuário fizer o $ vagrant destroy tudo voltará ao que era antes.

Vagrant Cachier

O Cachier é aquele cara que faz você se perguntar: como conseguiu viver sem ele até agora! Ele faz o cache dos pacotes Apt que você instala na suas distribuições Debian-like (Ubuntu inclusive) entre todas os projetos que você tiver baseado em uma box.

Assim, ele acelera (e muito!!!) a instalação das suas dependências, pois, se um pacote já tiver sido baixado naquela versão específica em um outro projeto, será usado o cache em vez de ir até o repositório oficial do Ubuntu, por exemplo.

Vagrant HostManager

Vai chegar o momento em que apenas definir um IP na opção :private_network do Vagrantfile, ou mesmo a redirecionamento de porta via :forwarded_port, não será mais suficiente para testar seu projeto (por diversos motivos isso pode acontecer. Acredite, quando você chegar nesse nível você vai lembrar das minhas palavras 😉 ).

Nesse momento você vai procurar uma forma de configurar o seu arquivo HOSTS, /etc/hosts (nos sistemas *nix) ou %windir%\system32\drivers\etc\hosts (no Windows), para que endereço do seu Vhost do Apache fique disponível tanto internamente nas máquinas (Guests) quanto a partir do seu sistema principal (Host). Qual é o caminho normal para fazer isso? Sim, editar manualmente seu arquivo HOST em um monte de lugares.

Aí que entra o plugin HostManager: com base numa pequena configuração do seu Vagrantfile ele já configura tudo isso para você. Existem alguns outros que fazem o serviço de forma parecida, mas foi com ele que me adaptei mais.

Considerações finais

Os plugins foram uma inclusão importante no ecossistema do Vagrant, e como viram, não é difícil de usar os que já estão disponíveis. Esse artigo está longe de te dar o caminho completo para usar as ferramentas, mas já te inicia e mostra onde você pode conseguir mais informações. Procure conhecer e testar o máximo que você conseguir pois assim vai ser fácil de tomar a decisão de usar ou não um deles em seus futuros projetos.

E fique a vontade de usar os comentários se quiser ajuda!

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.