tentei com ExtUtils::MakeMaker e Module::Install mas o Makefile saia com algum
erro, dai bati cabeça e consegui o tar.gz com o Dist::Zilla.
From: guedes_1...@hotmail.com
To: rio-pm@pm.org
Date: Sun, 3 Jun 2012 23:29:56 +0000
Subject: Re: [Rio-pm] MakeFile
Bem meu arquivo ficou assim:
##################################################################
use inc::Module::Install;
name 'P50Tools';
all_from 'lib/P50Tools.pm';
abstract 'This distribution compose a tools to work with pen-test, but just to
study';
author 'Aureliano Guedes <acpgue...@cpan.org>';
version '0.5';
license 'perl';
perl_version '5.006';
requires 'LWP::UserAgent' => 0;
requires 'HTTP::Request' => 0;
requires 'Net::RawIP' => 0;
requires 'Moose' => 0;
requires 'common::sense' => 0;
recommends 'LWP::Simple' => 0;
WriteAll;
#######################################################################
O problema é que quando executei o Makefile deu erro, em seguida não pude
executar o make manifest nem o make dist.
> Date: Sun, 3 Jun 2012 18:22:57 -0300
> From: br...@rio.pm.org
> To: rio-pm@pm.org
> Subject: Re: [Rio-pm] MakeFile
>
> 2012/6/3 Alexei Znamensky <rus...@gmail.com>:
> >
> >
> > 2012/6/3 Stanislaw Pusep <creakt...@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 <rus...@gmail.com>
> >>>
> >>>
> >>> 2012/6/3 breno <br...@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 <creakt...@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_1...@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@pm.org
> >>>> >> http://mail.pm.org/mailman/listinfo/rio-pm
> >>>> >
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Rio-pm mailing list
> >>>> > Rio-pm@pm.org
> >>>> > http://mail.pm.org/mailman/listinfo/rio-pm
> >>>> _______________________________________________
> >>>> Rio-pm mailing list
> >>>> Rio-pm@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@pm.org
> >>> http://mail.pm.org/mailman/listinfo/rio-pm
> >>
> >>
> >>
> >> _______________________________________________
> >> Rio-pm mailing list
> >> Rio-pm@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@pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> _______________________________________________
> Rio-pm mailing list
> Rio-pm@pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
_______________________________________________
Rio-pm mailing list
Rio-pm@pm.org
http://mail.pm.org/mailman/listinfo/rio-pm
_______________________________________________
Rio-pm mailing list
Rio-pm@pm.org
http://mail.pm.org/mailman/listinfo/rio-pm
