Incidentalmente, isso acabou de aparecer no meu feed ;-) http://my.opera.com/cstrep/blog/2012/06/07/dist-zilla-y-u-suddenly-no-work-anymore
[]s -b 2012/6/7 Alexei Znamensky <[email protected]>: > Bom, lá vou eu fazer papel de advogado do diabo :-) > > 2012/6/3 breno <[email protected]> > [...] > >> >> 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... > > > Acho que a parte de criar distribuições do zero veio até depois, se não me > falha a memória. Até porque já havia o Module::Starter. Eu pessoalmente acho > que a melhor parte do Dist::Zilla não são essas, mas sim o fato de que você > não tem de fazer "boilerplate maintenance" - coisas que estão aparecendo > neste thread como escrever README, escrever Changelog, etc.. - toda vez que > for soltar uma versão nova da sua distribuição. > > Antes de entrar nos detalhes abaixo, apenas um comentário: todo o > comportamento do Dist::Zilla é configurável, então nenhum dos comportamentos > descritos abaixo é obrigatório. > >> 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); > > > "dzil build" gera um build da sua distro no subdiretorio > ./Sua::Distrib-versao, onde você pode testar e debulhar seus arquivos. > > nos meus módulos com Dist::Zilla, até onde lembro, não tem alteração de > código-fonte Perl (e seus números de linha). A seção de POD no fim do > arquivo é quase toda gerada, entretanto. > > Minto, lembrei-me depois aqiu que eu uso o plugin PerlTidy, que executa o > Perl::Tidy em todo o código. Apesar de isso potencialmente dificultar a > colaboração de outros autores, eu acho que: > > 1) Não custa nada, de vez em quando eu rodar um Perl::Tidy contra todo o meu > código e dar um commit. > 2) Se eu não fizer isso, o meu códigio vai sair bem formatado mesmo assim > 3) A facilidade de leitura que o código bem formatado dá supera, na minha > opinião, a dificuldade em encontrar uma linha de código > >> >> * 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; > > > "dzil authordeps | cpanm" instala tudo o que você precisa. > > O que talvez ajudasse mais seria, au rodar o dzil e encontrar um Plugin ou > Bundle que não está instalado no sistema, ao invés de dar erro, perguntar se > quer instalar e já resolver tudo. > >> >> * 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; > > > O dzil não gera stubs de documentação de subs ou do código em si. O que ele > gera de stubs são as seções de um POD de Perl, e algumas das seções > "boilerplate" são preenchidas automagicamente, por exemplo: > > NAME > VERSION > SUPPORT > AUTHOR > COPYRIGHT > DISCLAIMER OF WARRANTY > > Ele não gera documentação de um método para o qual você não escreveu nada. > Assim, a decência ou indecência da documentação depende, como sempre > dependeu, somente do programador. Não vejo como isso esteja sendo estimulado > ou desestimulado pelo Dist::Zilla. > > Muito pelo contrário, com o uso de alguns plugins no Dist::Zilla, alguns > testes são incluídos na distribuição para melhorar a qualidade da mesma, > incluindo o testes de POD, que verificam se existe documentação gerada para > cada subrotina, caso não haja, ele não permite o release da distrbuição. > >> * 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 bundle faz aquilo que o autor da distribuição considerou importante que > fosse feito. Sou totalmente a favor de se ter alguns Bundles padronizados, > mas não sei se isso altera a crítica. Os bundles são módulos por si só, > então é possível abrir o mesmo e verificar o que eles fazem - não que você > precise saber para usar. > > se um dos plugins não funcionar no seu sistema, faz-se aquilo que sempre se > faz quando um módulo não funciona no sistema: se você estiver de bom humor, > investiga e manda um patch, se estiver mais ou menos voce apenas manda um > bug report para o owner, e se estiver de mal humor, desencana de fazer o > patch da distribuição-que-usa-o-dist-zilla, manda um report pro owner e fala > pra ele corrigir, e se estiver muito puto da vida desencana de tudo isso e > dane-se. > > lembrando que o dist-zilla (e seus plugins em quantidades boçais) não são > necessários para voce instalar o módulo, são usados APENAS para fazer o > build do pacote de distribuição, isto é, só será realmente necessário pelo > autor ou se você quiser fazer algum patch para o autor. > >> * 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. > > > O dzil automatiza testes também, então toda a "garantia" de qualidade que > você poderia ter sem ele, você pode ter com ele. Na verdade, uma vez que eu > criei o meu bundle de plugins, que inclui varios testes para qualidade de > código, eu tenho tantas garantias quanto eu sempre tive sem ele. > > Seguindo a sua lógica, o script de cpan-upload é tão ruim quanto. But then > again, eu acho que você está atirando no mensageiro. O CPAN é, por sua > natureza, um repositório aberto, que aceita tantos e quantos módulos > houverem para se publicar. Se eu, num ataque de loucura insana, decidir > fazer um Denial-of-service no CPAN, eu poderia simplesmente gerar > distribuições aleatórias e subí-los com o cpan-upload - não sei qual seria o > limite até onde eu poderia fazer isso, mas em algum momento o indexador e/ou > o ftp do CPAN iriam abrir o bico (imagine os mirrors puxando milhares de > módulos a mais, da noite pro dia). O *** CPAN *** permite que módulos sejam > subidos facilmente, não é o Dist::Zilla. > > Não exatamente, mas seguindo emuma linha parecida com a que conversamos no > outro dia, se houvesse um **outro** repositório, onde neguinho não pode sair > colocando qualquer coisa, isso sim daria alguma garantia. > >> >> 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 > > > Podemos, e continuamos assim. :-) > > Ao usar o Module::Install, você tem de gerar Makefile.PL e mais um monte de > outras coisas, CADA VEZ que for soltar uma versão nova da distribuição. Com > o Dist::Zilla, você automatiza essa parte - inclusive depois de dominar os > Bundles, você automatiza a inclusão de incontáveis suítes de teste prontas > nas suas distribuições. > > my $two_cents; > > []s, > Russo > >> >> 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 <[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 >> _______________________________________________ >> 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
