<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Em 05-12-2010 12:57, Adriano Ferreira escreveu:
<blockquote
cite="mid:AANLkTimXa-ditxC8FuOxmX3zXbjjSUQRczH91UAUBY_O@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">2010/12/5 Alexei Znamensky <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:russoz@gmail.com">russoz@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="gmail_quote">
<div><br>
</div>
<div>Eu procurei por Business::BR::Ids (que é módulo, mas
que também é o nome =~ s/-/::/g do tar ball. Na hora,
presumi que funcionaria isso.</div>
</div>
</blockquote>
</div>
<br>
<div>O negócio é que as distribuições (ou tarballs) como coleções
de packages podem mudar à vontade do desenvolvedor (embora isto
não aconteça muito na prática, mas que acontece, acontece). Mas
só esta possibilidade cria um problema muito grande para mapear
dependências de módulos (ou packages) para distribuições.</div>
<div><br>
</div>
<div>Pensando um pouco, o negócio é que as dependências dos
packages em uma distribuição deviam incluir os packages da
própria distribuição, algo assim:</div>
<div><br>
</div>
<div> Business::BR::CPF depende de Business::BR::Id (esteja
ou não no mesmo pacote)</div>
<div><br>
</div>
<div>mas isto é um "can of worms" devido à dificuldade de descobir
dependências olhando em código fonte Perl – é fácil encontrar
"require M" e "use M", mas que tal</div>
<div><br>
</div>
<div> $M->require (com UNIVERSAL::require)</div>
<div> load($M) (com Module::load)</div>
<div> eval STRING </div>
<div><br>
</div>
<div>e muitas outras formas de fazer o "link" dinâmico entre
módulos. E tem mais, alguns destes "statements" serão
dependências reais e outros módulos que colaboram. Neste último
caso, só análise semântica feita por um humano seria capaz em
alguns casos de fazer uma decisão acertada a respeito.</div>
<br>
</blockquote>
Outro fator, é a inclusão de módulos novos em distribuições novas do
Perl, ou seja um módulo pode ser dependente na versão 5.8 e na
versão 5.10 não... e dependendo do teu cenário você pode "se
esquecer" de adicionar esta dependência.<br>
<br>
Russo,<br>
<br>
Talvez você espera-se algo como o Test::UseAllModules ou
Test::Compile, porem mesmo assim você terá problemas dependendo do
teu cenário.<br>
<br>
Por isto o CPAN::Testers é sensacional. :-) Acredito que a função
das dependências é estritamente para oferecer o pacote no maior
número de cenários possiveis, seja plataforma, distribuições,
versões e etc.. E não uma inteligencia para saber se alguém escreveu
determinado módulo, acredito que isto com informações (nome,
documentação) para ser encontrados basta, afinal é por isto que
falamos e falam tanto do CPAN.<br>
<br>
Por exemplo, o módulo que você criticou pela dependência "errada",
segundo o CPAN::Testers resolve bem o problema na questão de
funcionalidade:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.cpantesters.org/distro/M/MooseX-Types-CPF.html#MooseX-Types-CPF-0.02">http://www.cpantesters.org/distro/M/MooseX-Types-CPF.html#MooseX-Types-CPF-0.02</a><br>
<br>
Graças ao trabalho do Adriano no Bussiness::BR que já é um módulo de
qualidade para a tarefa e ao Moose::Types, a minha tarefa foi apenas
apontar para eles. ;-)<br>
<br>
Abs!<br>
-Thiago Rondon<br>
<br>
</body>
</html>