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