Re: [Rio-pm] MakeFile

[Fernando Corrêa de Oliveira]

Provavelmente oq vc tá procurando seja POD.
Just Another Perl Hacker
Fernando Corrêa de Oliveira
fernandocor...@gmail.com

Em 07/06/2012, às 13:54, Aureliano Guedes escreveu:

 Assim, toda distribuição, quando o autor submete ao CPAN, tem uma 
 documentação. Essa documentação vai junto ao *.tar.gz?? Ela é o arquivo 
 README, certo??
 Tem alguma formatação especial para o arquivo README ou eu posso escrever 
 essa documentação da forma que eu preferir??
 Ela precisa estar em formato html ou pode ser escrito normal?
 
  Date: Wed, 6 Jun 2012 21:29:58 -0300
  From: br...@rio.pm.org
  To: rio-pm@pm.org
  Subject: Re: [Rio-pm] MakeFile
  
  2012/6/6 Aureliano Guedes guedes_1...@hotmail.com:
   Breno, desculpa por não ter detalhado o erro.
  
   So minha ultima pergunta, o arquivo README, é so simplesmente escrever e
   colocalo na mesma pasta lib onde esta o modulo ou tem algo a mais em
   especial nele,
   exemplo, formatação, uso de um modulo para escreve-lo, etc...
  
  
  Do que você está falando? Lembra que não estamos aí do seu lado e nem
  fazemos idéia do que vc quer fazer (eu, pelo menos, não faço idéia =)
  
  
  []s
  
  -b
  ___
  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

Re: [Rio-pm] MakeFile

[Alexei Znamensky]

Bom, lá vou eu fazer papel de advogado do diabo :-)

2012/6/3 breno br...@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 

Re: [Rio-pm] MakeFile

[breno]

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 rus...@gmail.com:
 Bom, lá vou eu fazer papel de advogado do diabo :-)

 2012/6/3 breno br...@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 

Re: [Rio-pm] MakeFile

[breno]

2012/6/4 Aureliano Guedes guedes_1...@hotmail.com:

 O problema é que quando executei o Makefile deu erro, em seguida não pude
 executar o make manifest nem o make dist.


Oi Aureliano,

que bom que conseguiu se entender com o Dist::Zilla. Uma dica: da
próxima vez que tiver problema com alguma coisa, não diga tentei mas
deu erro. Diga o que exatamente vc fez e qual foi o erro (de
preferência com a mensagem), senão fica difícil ajudar =)

[]s

-b
___
Rio-pm mailing list
Rio-pm@pm.org
http://mail.pm.org/mailman/listinfo/rio-pm

Re: [Rio-pm] MakeFile

[Aureliano Guedes]

Breno, desculpa por não ter detalhado o erro.

So minha ultima pergunta, o arquivo README, é so simplesmente escrever e 
colocalo na mesma pasta lib onde esta o modulo ou tem algo a mais em especial 
nele,
exemplo, formatação, uso de um modulo para escreve-lo, etc...

 Date: Wed, 6 Jun 2012 12:51:40 -0300
 From: br...@rio.pm.org
 To: rio-pm@pm.org
 Subject: Re: [Rio-pm] MakeFile
 
 2012/6/4 Aureliano Guedes guedes_1...@hotmail.com:
 
  O problema é que quando executei o Makefile deu erro, em seguida não pude
  executar o make manifest nem o make dist.
 
 
 Oi Aureliano,
 
 que bom que conseguiu se entender com o Dist::Zilla. Uma dica: da
 próxima vez que tiver problema com alguma coisa, não diga tentei mas
 deu erro. Diga o que exatamente vc fez e qual foi o erro (de
 preferência com a mensagem), senão fica difícil ajudar =)
 
 []s
 
 -b
 ___
 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

Re: [Rio-pm] MakeFile

[Aureliano Guedes]

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 +
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

Re: [Rio-pm] MakeFile

[Aureliano Guedes]

Breno e Stan, muito obrigado, eu acho que com isso ja ficou muito bem mais 
claro a questão do MakeFile.

Darei um feedback se consegui ou não, obrigado.



 Date: Sun, 3 Jun 2012 00:54:00 -0300
 From: br...@rio.pm.org
 To: rio-pm@pm.org
 Subject: Re: [Rio-pm] MakeFile
 
 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).
 
 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

Re: [Rio-pm] MakeFile

[Alexei Znamensky]

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 

Re: [Rio-pm] MakeFile

[Stanislaw Pusep]

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.

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 

[Rio-pm] MakeFile

[Aureliano Guedes]

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