Valeu mesmo pelas dicas Blabos. Esclareceu bastante tambem a funcao do underline. Vou tentar desse jeito entao pra validar o processo do inicio ao fim antes de um release publico. Que bom saber que agora os procedimentos estao ainda melhores, vou dar um olhada no dzil. Estava ate agora usando o que o Padre oferece, que para a Fase 1 e 2 deu certo, mas e bem capaz que precise de algo mais para criar a distribuicao que vai subir pro CPAN.
Abs 2014-05-20 20:26 GMT-07:00 Blabos de Blebe <bla...@gmail.com>: > Ao colocar o underline na versão, vc evita que os instaladores usem essa > versão inadvertidamente, embora ela ainda seja instalável se for > especificado o caminho completo para o pacote. > > Assim, você pode usar a infra-estrutura do cpan testers pra testar o seu > módulo antes de um release público, sem prejudicar quem já está usando uma > versão estável do seu módulo. > > O Dist::Zilla não é uma unanimidade, embora eu o utilize na maioria dos > meus módulos públicos ou privados. Eventualmente pode ser chato lidar com > alguns bugs em edge cases, mas normalmente ele tira muito boiler plate da > sua frente. > > A vantagem do dzil é que ele encapsula o acesso a ferramentas de várias > fases do processo de desenvolvimento, desde o startup do módulo até o > release no cpan. > > Eventualmente você pode dividir esse processo em algo como: > > 1) Fase 1: Fazer o bootstrap do seu pacote. > > Isso significa criar os diretórios padrão (/lib, /t, etc) bem como os > arquivos auxiliares. > > Além do dzil, um aplicativo que eu uso pra fazer o bootstrap dos meus > módulos é o https://metacpan.org/pod/Module::Starter > > Com ele você pode escolher qual builder você vai utilizar pra montar o seu > pacote. > > 2) Fase 2: code, code, code > > 3) Fase 3: Build > > No processo de build, uma peça de software é utilizada para juntar tudo > que o seu pacote vai precisar para ser instalado em uma máquina qualquer. > > Essa etapa pode ser baseada em vários builders como: > > https://metacpan.org/pod/ExtUtils::MakeMaker > https://metacpan.org/pod/Module::Build > https://metacpan.org/pod/Module::Install > > Esses builders baseiam-se em arquivos perl (Makefile.PL, Build.PL, etc) > para a partir de apontamentos que você faz, verificar as dependências, > criar o Makefile e seus alvos,gerar o .tar.gz entre outras coisas > necessárias para tornar o seu módulo instalável. > > Quando vc instala um módulo manualmente, normalmente o processo é: > > a) Baixar e descompactar o .tar.gz > b) perl Makefile.PL (ou perl Build.PL). Isso vai criar um arquivo Makefile > adaptado pra sua máquina. > c) make. Isso vai fazer o build do seu módulo, eventualmente compilando > XS, se for o caso, etc > d) make test. Lê o Makefile para executar os testes do seu módulo. > e) make install > > Quando você cria um módulo, para montar o .tar.gz normalmente você faz: > > a) perl Makefile.PL (ou perl Build.PL). Isso vai criar um arquivo Makefile > adaptado pra sua máquina. > b) make manifest. Isso vai criar uma lista com todos os arquivos que > precisam ser distribuídos dentro do seu .tar.gz > c) make dist. Isso vai criar um .tar.gz do seu módulo, dentro do qual, > haverá um Makefile.PL (ou Build.PL), e *não* um Makefile. > > Os arquivos *.PL precisam ser executados no momento da instalação para que > o Makefile seja montado de acordo com a máquina onde ele está sendo > instalado e não de acordo com a máquina onde o módulo foi criado. > > > 4) Release. > > Consiste em enviar o seu módulo para o CPAN. > > *** > > O Module::Make eu vou desconsiderar, porque ele só tem uma versão antiga > lançada e nenhum outro módulo do cpan o utiliza ( > https://metacpan.org/requires/distribution/Module-Make?sort=[[2,1]]). > > *** > > Com o dzil você tem uma ferramenta, que em conjunto com plugins cobre > todas as etapas listadas acima e mais algumas outras, como integração com o > seu sistema de controle de versão e simplificação da criação de POD, por > exemplo. > > Já se você preferir fazer sem ele, você pode fazer tudo manualmente, ou > usar qualquer dessas ferramentas citadas acima pra cobrir uma fase ou > outra, ou ainda combiná-las entre si. > > Eu particularmente tenho módulos que usam o dzil ( > https://github.com/blabos/Dancer2-Plugin-Paginator) e módulos que não > usam (https://github.com/blabos/Paginator-Lite). > > E quando não uso, tenho preferência por criar o módulo com o > Module::Starter (não confundir com https://metacpan.org/pod/Module::Start) > usando como builder o Module::Install. > > *** > > Finalizando, só preste atenção no que você deseja fazer e escolha a > ferramenta que achar mais adequada, tendo em mente que embora seja > relativamente simples criar um módulo e botar no CPAN, há várias etapas > envolvidas, que na maioria das vezes já são até instintivas, mas que se > você misturar as coisas, pode dar a maior confusão. > > []'s > > > > > > > 2014-05-20 16:12 GMT-03:00 Aureliano Guedes <guedes_1...@hotmail.com>: > > >Sim, passei o olho nisso, mas meio que ignorei pois o mesmo usa >> Dist::Zilla e lembro que os 2 metodos mais recomendados eram >Module::Build >> e Module::Make. >> >> Posso estar enganado, mas esses 'eram' os mais recomendados. O >> Dist::Zilla é mais recente porem creio que seja o melhor e atualmente o >> 'mais recomendado'. >> >> ------------------------------ >> Date: Tue, 20 May 2014 11:52:43 -0700 >> From: samircu...@gmail.com >> To: rio-pm@pm.org >> Subject: Re: [Rio-pm] Release de modulo Beta no CPAN >> >> >> Sim, passei o olho nisso, mas meio que ignorei pois o mesmo usa >> Dist::Zilla e lembro que os 2 metodos mais recomendados eram Module::Build >> e Module::Make. >> >> Lendo melhor, parece que rola uma discussao entre usar as flags oficiais >> do CPAN ou _ na versao. Hum. >> >> Meio tosco que as flags oficiais do CPAN sao mais inuteis do que um _ na >> versao. Mas o argumento da confusao no metacpan faz sentido. >> >> De qualquer jeito quando visito a pagina um modulo nao vejo a flag la : >> >> http://search.cpan.org/~ingy/Module-Make-0.01/lib/Module/Make.pm >> >> Entao de repente o melhor e fazer como o "ingy" e colocar uma nota no POD. >> >> Abs >> >> >> 2014-05-20 11:39 GMT-07:00 Renato Santos <renato.c...@gmail.com>: >> >> * >> http://blogs.perl.org/users/oliver_gorwits/2011/10/releasing-trialdevbeta-versions-with-distzilla.html >> >> #fastreply >> >> >> 2014-05-20 15:35 GMT-03:00 Samir Cury <samircu...@gmail.com>: >> >> Pessoal, >> >> Outro dia na lista, li alguem dizendo : manda pro CPAN logo como "beta" >> >> Como estou no passo intermediario para o meu primeiro modulo "decente", >> com testes e tudo mais, talvez nao tenha visto essa opcao ainda. >> Pesquisando um pouco esbarrei com todas essas definicoes : >> >> http://search.cpan.org/dlsip?bpmOp >> >> Ja que o modulo funciona, esta documentado e passa no "prove", achei >> interessante subir como beta, e lancar novas releases quando fizer mais >> refatoracoes. >> >> Enfim. Queria confirmar com a galera que ja trilhou este caminho, que >> quando eu for realmente subir o modulo vou ter a opcao de marcar como beta. >> >> Pra quem estiver curioso este e o modulo : >> >> https://github.com/samircury/HTCondor--Queue--Parser >> >> Abs, >> Samir >> >> >> >> _______________________________________________ >> Rio-pm mailing list >> Rio-pm@pm.org >> http://mail.pm.org/mailman/listinfo/rio-pm >> >> >> >> >> -- >> Saravá, >> Renato CRON >> http://www.renatocron.com/blog/ >> @renato_cron <http://twitter.com/#%21/renato_cron> >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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
