[Rio-pm] MakeFile

breno breno em rio.pm.org
Quinta Junho 7 16:39:20 PDT 2012


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 <russoz em gmail.com>:
> Bom, lá vou eu fazer papel de advogado do diabo :-)
>
> 2012/6/3 breno <breno em rio.pm.org>
> [...]
>
>>
>> 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 <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
>> _______________________________________________
>> 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