[Rio-pm] Release de modulo Beta no CPAN

Terça Maio 20 20:26:09 PDT 2014

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_1000 em 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: samircurys em gmail.com
> To: rio-pm em 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.cron em 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 <samircurys em 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 em 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 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
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20140521/1e315f13/attachment-0001.html>