[Rio-pm] MakeFile

breno breno em rio.pm.org
Domingo Junho 3 14:22:57 PDT 2012


2012/6/3 Alexei Znamensky <russoz em gmail.com>:
>
>
> 2012/6/3 Stanislaw Pusep <creaktive em gmail.com>
>>
>> Concordo com ambos :)
>> Alexei, o seu tutorial sobre Dist::Zilla me poupou algumas horas de
>> tarefas repetitivas. Mas antes disso, eu escrevia Makefile.PL manualmente.
>> Isso me fez passar menos raiva com a (falta de) documentação do
>> Dist::Zilla. Ele é uma típica coisa "como não pensei nisso antes", tal qual
>> "set -o vi" no Bash :P.
>> É prático para quem conhece o bé-a-bá, mas pouquíssimo didático.
>
>
> Então, ao invés de fazer as coisas como se fazia em 1997, ou se criar um
> novo, por que não melhorar o que falta no Dist::Zilla (incluindo
> documentação, que eu concordo, é um lixo) para podermos nos esquecer de vez
> dos detalhes sórdidos?
>

Acho que são problemas distintos. O Dist::Zilla foi criado para
facilitar a criação de novas distribuições do zero, bem como a
atualização dessas distribuições dentro do seu workflow (git, cpan,
etc). Isso envolve a geração automática de um montão de coisas,
inclusive de um Makefile.PL usando o builder que você escolher no seu
~/.dzil/profile, o que é *muito* legal. Mas...

Minhas críticas quanto ao Dist::Zilla são muito simples:

   * Ele altera o seu código fonte, o que para mim dificulta a
depuração de bugs ("erro na linha X" e lá vamos nós abrir a versão
instalada pra achar o bug e o original para consertá-lo);

   * Com arquivos auto-gerados (incluindo testes e Makefile.PL), ele
dificulta a colaboração de autores, que precisam instalar o Dzil e
todos os plugins que você usa no seu projeto, do contrário não vão
conseguir testar o patch que fizeram pois não dá pra montar a sua
distribuição. Isso é facilmetne resolvido distribuindo o Makefile.PL
auto-gerado junto com a sua distribuição, mas não vejo isso acontecer;

   * A geração de stubs de documentação genérica aparentemente
desestimula autores a escrever documentação decente; Há um módulo
muito bacana chamado Pod::Plexus sendo desenvolvido pelo Rocco Caputo,
mas ainda assim o problema persiste;

   * A quantidade boçal de plugins e configurações acaba estimulando a
criação de bundles com plugins específicos de um autor. Se vc vai
contribuir num projeto do Russo e vê um dist.ini contendo [@RUSSOZ], o
que que isso faz? E se um dos plugins (que são específicos de cada
autor) não funcionar no seu sistema? Temos aí um caso em que o próprio
Dist::Zilla foi vítima de facilitadores para criação de configurações
padrão;

   * O dzil é muito voltado para subir módulos no CPAN e de fato é
literalmente um comando para subir a nova versão. Mas isso acaba, do
meu ponto de vista, facilitando a publicação equivocada de módulos, o
que é particularmente preocupante se vc não quer essa distribuição no
CPAN ou se ela é uma distribuição delicada/popular e vc precisa de uma
certa garantia de qualidade ou pode quebrar sem querer o código dos
outros. Tudo isso pode ser resolvido tomando cuidado e com boas
práticas de desenvolvimento, mas exigem treinamento e disciplina.

Para o problema em questão ("como gerar uma distribuição perl"), a
criação do Makefile.PL usando a API do Module::Install me parece ser
mais fácil e com uma curva de aprendizado muito menor que a
criação/configuração do dzil.ini. Mas podemos concordar em discordar
:P

Dito isso, continuo afirmando que o Dist::Zilla é uma ótima solução
para quem tem os problemas que ele se propõe a corrigir. Da minha
parte, prefiro usar a combinação "module-starter" e "cpan-upload" =)


[]s

-b

>>
>>
>> ABS()
>>
>>
>>
>>
>> 2012/6/3 Alexei Znamensky <russoz em gmail.com>
>>>
>>>
>>> 2012/6/3 breno <breno em rio.pm.org>
>>>>
>>>> Ao contrário do Stan, eu não recomendo o Dist::Zilla. Ou pelo menos
>>>> não pra vc que está começando. Pode ser uma ótima ferramenta para
>>>> alguns autores, mas se vc não entende a "mágica" que acontece por
>>>> trás, pode se confundir e te deixar mais tempo configurando/depurando
>>>> as ferramentas em vez de trabalhando no(s) seu(s) próprio(s)
>>>> módulo(s).
>>>
>>>
>>> Ao contrário do Garu, eu não des-recomendo o Dist::Zilla. Eu acho que é
>>> uma ferramenta fantástica para esconder do desenvolvedor de distribuições os
>>> detalhes de um build. Ao invés de tentarmos difundir ao máximo os detalhes,
>>> para que todos - teoricamente - saibam o que fazer quando houver um
>>> problema, acho que é muito mais saudável para todos que os detalhes sujos
>>> fiquem o mais escondidos e automatizados o possível, simplificando a vida de
>>> todos, mas principalmente de quem está começando.
>>>
>>> Filosofando um pouco mais sobre o assunto, na rabeira de uma longa
>>> conversa que eu e o Breno tivemos por telefone outro dia, eu fico pensando
>>> que "More Than One Way To Do It" é muito bom como possibilidade, como para
>>> ser usado em caso de exceção. Não deveria ser a regra. É muito bom que haja
>>> 2,3,4, 5 formas diferentes de expressar orientação a objeto, contanto que
>>> uma delas fosse uma "regra" e as outras fossem casos de exceção, aplicados
>>> para necessidades específicas (e de preferência bem definidas, se não for
>>> pedir muito). É muito bom estarmos todos produzindo e usando código livre, e
>>> se eu quiser mudar algo eu posso simplesmente alterar e fazer o que eu
>>> quiser, mas ó céus cada módulo que eu for fuçar é uma caixinha de surpresas.
>>> Uns são feitos em Moose, outros em Mouse, tem um novo agora que eu nem
>>> gravei o nome, tem os caras que fazem o bless na mão, e tem os caras que
>>> fazem magia negra. Ou seja, se eu quiser ser um bom (=bondoso, cooperativo,
>>> ativo, colaborativo, etc..) programador Perl, eu preciso ser fluente em uns
>>> 5 ou 6 tipos diferentes de expressar a mesma idéia. Ao invés de poder contar
>>> que algo vai ser de um jeito (ou de outro), e seguir adiante, e produzir 5
>>> ou 6 idéias novas.
>>>
>>> Fala-se, volta e meia, sobre produtividade em Perl e em Java, o
>>> boilerplate code em Java é muito grande, etc.., mas toda vez que eles
>>> (javeiros) precisam mexer em código dos outros, existe um padrão mínimo de
>>> consistência esperado (claro, sempre há quem ferre com isso, em qualquer
>>> idioma). Enquanto que, mexer em código dos outros, em Perl, como eu disse, é
>>> um Kinder Ovo. You never know what you gonna get. Talvez esse seja o motivo,
>>> na minha humirde opinião, pelo qual, eu percebo mais programadores Perl no
>>> perfil "lobo solitário" do que em Java, por exemplo. É mais fácil às vezes
>>> fazer um novo que entender o dialeto que o outro cara utiliza.
>>>
>>> my $0.02;
>>>
>>>>
>>>> Respondendo a sua pergunta, os arquivos Makefile.PL existem para a
>>>> criação de "distribuições", que podem conter um ou mais módulos (além
>>>> de scripts e outros arquivos). Quando vc faz uma distribuição, não tem
>>>> problema se os módulos dentro dela dependerem de outro, contanto que
>>>> esse outro também esteja dentro da distribuição (mas tenha cuidado com
>>>> dependências circulares!).
>>>>
>>>> Há 3 construtores populares:
>>>>
>>>>  * ExtUtils::MakeMaker, a.k.a. EUMM (que vc já citou)
>>>>  * Module::Build, a.k.a MB
>>>>  * Module::Install, a.k.a. MI
>>>>
>>>> Embora o EUMM esteja no core, o M:I tem uma DSL bem fácil de usar e é
>>>> utilizado em projetos de grande porte como Catalyst.
>>>>
>>>> Digamos que vc tenha a seguinte estrutura de módulos:
>>>>
>>>> lib/
>>>> lib/MeuModulo.pm
>>>> lib/MeuModulo
>>>> lib/MeuModulo/Modulo1.pm
>>>> lib/MeuModulo/Modulo2.pm
>>>>
>>>> e queira criar uma distribuição chamada "Minha-Dist" contendo isso
>>>> tudo. A sintaxe do seu Makefile.PL é muito simples:
>>>>
>>>> ---------------8<---------------
>>>> use inc::Module::Install;
>>>>
>>>> name    'Minha-Dist';
>>>> all_from  'lib/MeuModulo.pm';
>>>>
>>>> WriteAll;
>>>> --------------->8---------------
>>>>
>>>> Pronto. Fácil, não? Ao rodar "perl Makefile.PL" ele vai gerar alguns
>>>> arquivos pra vc. Depois digite "make manifest" e "make dist" e vc terá
>>>> um Minha-Dist-0.01.tar.gz te esperando, pronto pra ser instalado =)
>>>>
>>>> Algumas observações sobre o Makefile.PL acima:
>>>>
>>>> * "name" indica o nome da distribuição. A convenção é que vc use o
>>>> mesmo nome do seu módulo base, o principal da sua distribuição (e que
>>>> provavelmente a maioria das pessoas vai usar primeiro). No seu caso,
>>>> suponho que o melhor "name" para a sua distribuição seria "MeuModulo".
>>>>
>>>> * "all_from" indica de onde o Makefile.PL deve extrair informações
>>>> como versão, licença, autor, resumo, etc. Ele extrai essa informação
>>>> de variáveis especiais de módulos (como "our $VERSION") e da
>>>> documentação - então não esqueça de incluir os campos pertinentes na
>>>> documentação (sempre uma boa prática!) ou terá que inclui-los
>>>> explicitamente no Makefile.PL.
>>>>
>>>> Digamos que os módulos da sua distribuição dependam dos seguintes
>>>> módulos EXTERNOS: File::Spec e Carp. Digamos ainda que, embora não
>>>> seja uma dependência direta, se o usuário tiver instalado o módulo
>>>> Data::Printer o seu programa consegue fazer alguma outra coisa bacana,
>>>> então embora não seja obrigatório vc gostaria de recomendar o
>>>> Data::Printer. Adicionar essas dependências no Makefile.PL é simples,
>>>> ele fica assim:
>>>>
>>>> ---------------8<---------------
>>>> use inc::Module::Install;
>>>>
>>>> name    'Minha-Dist';
>>>> all_from  'lib/MeuModulo.pm';
>>>>
>>>> requires 'File::Spec' => 0;
>>>> requires 'Carp' => 0;
>>>>
>>>> recommends 'Data::Printer' => 0.3;
>>>>
>>>> WriteAll;
>>>> --------------->8---------------
>>>>
>>>> O número depois da "=>" indica a versão mínima do módulo, usamos zero
>>>> (0) para indicar que qualquer versão serve.
>>>>
>>>> Com isso acho que vc já tem o suficiente. Não esqueça de criar um
>>>> diretório "t" na raiz da sua distribuição para colocar os testes de
>>>> seus módulos!! Mais sobre o M:I vc encontra na documentação
>>>> (https://metacpan.org/module/Module::Install)
>>>>
>>>> Obs: quando criamos um novo módulo, há alguns "boilerplates" que criam
>>>> as estruturas e documentações básicas para vc. Eu particularmente
>>>> gosto do Module::Starter, com o plugin Module::Starter::PBP (mas eu
>>>> modifico os templates em ~/.module-starter/PBP para conter o esqueleto
>>>> que uso). Assim, basta escrever na linha de comando:
>>>>
>>>> $ module-starter --module="Meu::Novo::Modulo"
>>>>
>>>> e ele cria tudo para mim.
>>>>
>>>> Quando vc estiver acostumado a criar suas distribuições e entender o
>>>> processo, vai começar a ficar preguiçoso. Aí sim, dê uma olhada no
>>>> Dist::Zilla e veja se ele é para vc =)
>>>>
>>>>
>>>> []s
>>>>
>>>> -b
>>>>
>>>> 2012/6/2 Stanislaw Pusep <creaktive em gmail.com>:
>>>> > A resposta é: Dist::Zilla.
>>>> > Pode parecer chatinho de aprender, mas, uma vez sabendo o básico,
>>>> > criar
>>>> > módulo com Makefile.PL completo e suíte de testes é dois palitos!
>>>> > Recomendo:
>>>> >
>>>> > http://sao-paulo.pm.org/artigo/2011/OhnoItsDistZilla
>>>> > http://sao-paulo.pm.org/equinocio/2011/set/2
>>>> >
>>>> > ABS()
>>>> >
>>>> >
>>>> >
>>>> > 2012/6/2 Aureliano Guedes <guedes_1000 em hotmail.com>
>>>> >>
>>>> >> Ola,
>>>> >> Monges.
>>>> >>
>>>> >> Eu estou tentando gerar um MakeFile.PL mas estou com um problema.
>>>> >> Eu andei lendo, inclusive alguns materiais do Hernan Lopes mas ficou
>>>> >> uma
>>>> >> pergunta.
>>>> >>
>>>> >> Quando eu tenho varios modulos que na verdade sao dependencia de
>>>> >> outro
>>>> >> modulo.
>>>> >> exemplo:
>>>> >> MeuModulo.pm,
>>>> >> MeuModulo/Modulo1.pm,
>>>> >> MeuModulo/Modulo2.pm.
>>>> >>
>>>> >> Como faco?
>>>> >>
>>>> >> Nao achei nenhuma opcao no ExtUtils::MakeMaker.
>>>> >>
>>>> >> Desde ja, obrigado.
>>>> >> Att,
>>>> >>
>>>> >> Aureliano Guedes
>>>> >>
>>>> >> PS: Desculpem a falta de acentos, o teclado esta desconfigurado.
>>>> >>
>>>> >> _______________________________________________
>>>> >> Rio-pm mailing list
>>>> >> Rio-pm em pm.org
>>>> >> http://mail.pm.org/mailman/listinfo/rio-pm
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Rio-pm mailing list
>>>> > Rio-pm em pm.org
>>>> > http://mail.pm.org/mailman/listinfo/rio-pm
>>>> _______________________________________________
>>>> Rio-pm mailing list
>>>> Rio-pm em pm.org
>>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>>
>>>
>>>
>>>
>>> --
>>> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
>>> GPG fingerprint = 42AB E78C B83A AE31 7D27  1CF3 C66F B5C7 71CA 9F3C
>>> http://www.flickr.com/photos/alexeiz | http://github.com/russoz
>>> "I don't know... fly casual!" -- Han Solo
>>>
>>> _______________________________________________
>>> Rio-pm mailing list
>>> Rio-pm em pm.org
>>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm em pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>
>
>
>
> --
> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
> GPG fingerprint = 42AB E78C B83A AE31 7D27  1CF3 C66F B5C7 71CA 9F3C
> http://www.flickr.com/photos/alexeiz | http://github.com/russoz
> "I don't know... fly casual!" -- Han Solo
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm


Mais detalhes sobre a lista de discussão Rio-pm