2012/6/3 Stanislaw Pusep <[email protected]> > 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? > > ABS() > > > > > 2012/6/3 Alexei Znamensky <[email protected]> > >> >> 2012/6/3 breno <[email protected]> >> >>> 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 <[email protected]>: >>> > 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 <[email protected]> >>> >> >>> >> 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 >>> >> [email protected] >>> >> http://mail.pm.org/mailman/listinfo/rio-pm >>> > >>> > >>> > >>> > _______________________________________________ >>> > Rio-pm mailing list >>> > [email protected] >>> > http://mail.pm.org/mailman/listinfo/rio-pm >>> _______________________________________________ >>> Rio-pm mailing list >>> [email protected] >>> 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 >> [email protected] >> http://mail.pm.org/mailman/listinfo/rio-pm >> > > > _______________________________________________ > Rio-pm mailing list > [email protected] > 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 [email protected] http://mail.pm.org/mailman/listinfo/rio-pm
