<br><br><div class="gmail_quote">---------- Mensagem encaminhada ----------<br>>De: <b class="gmail_sendername">Tiago Peczenyj</b> <span dir="ltr"><<a href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>></span><br>

>Data: 15 de junho de 2011 11:27<br>>Assunto: Re: [SP-pm] Teen sells Perl cloud startup to ActiveState<br>>Para: <a href="mailto:saopaulo-pm@mail.pm.org">saopaulo-pm@mail.pm.org</a><br>><br>><br>>Aproveitando para mudar um pouco de assunto mas dentro do tema.<br>


><br>>Qual seria a melhor forma de fazer deploy do Catalyst (ou Dancer, ou<br>>Mojo) em produção? Eu poderia instalar via .deb ou .rpm OU preciso<br>>instalar todos os pacotes "na mão"? Dentro das dependências do<br>

>Catalyst tem algo que existe build essencials (gcc)?<br>
<br></div><div class="gmail_quote">Não sei como é a melhor maneira de fazer um deploy de uma aplicação Catalyst. A minha primeira alternativa era o local::lib, e agora estou pensando com carinho no perlbrew, mas realmente não sei.</div>

<div class="gmail_quote"><br>>Pergunto pq eu trabalho fazendo deploy em maquinas CentOS e sempre<br>>tenho que fazer RPMs para fazer deploy de aplicações em Perl mas todos<br>>eram scripts standalone ou serviços rodados via crontab.<br>


<br></div><div class="gmail_quote">Eu tenho a vontade de fazer um repositório de todos os módulos do cpan para todas as distros (inclusive o Windows), assim já estaria tudo empacotado.</div><div class="gmail_quote"><br>>Atualmente estamos usando para web Python, Ruby e Java e em cada um a<br>

>gerência de pacotes é estressante: no caso do Python podemos utilizar<br>>o pip mas recentemente tivemos uma divergencia com a versão de libcurl<br>>que consumiu 2 dias inteiros. Com rubygems ocorre a mesma coisa e Java<br>

>ficou abandonado (com todos os jars no mesmo diretorio... adivinhem o<br>>que acontece? ClassLoaderHell! mas isso é erro de projeto...).<br>
></div><div class="gmail_quote"><br></div><div class="gmail_quote">Recentemente a Mac fez uma coisa que 'congelou' e dificultou muito a instalação de módulos via cpan. Na <a href="http://london.pm">london.pm</a> teve uma longa thread sobre o assunto e uma das explicações (a de que o Mac depende do perl em algumas partes críticas, e por isto eles querem que vc utilize um perl diferente dos deles - se é que isto é verdade) me fez concluir que eu também quero isto no meu sistema. Eu como sysadmin gostaria que a aplicação ficasse contida inteira no diretório dela, e para isto parece que o perlbrew é o caminho para isto.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">>Não vejo como o CPAN poderia resolver o meu problema e estou inclinado<br>>a gerar RPMs (preferia gerar .deb mas fazer o que...). Sinto que estou<br>>olhado o problema pela perspectiva errada, mas começo a concordar que<br>

>servidor de produção não deve ter gcc ou build-essencials e utilizar<br>>multiplos gerenciadores de pacotes num ambiente sem a disciplina de<br>>gerência de configuração (pelo menos começamos a usaro Puppet! um<br>

>passo de cada vez...) é complicado para dizer o mínimo.<br>
></div><div class="gmail_quote"><br></div><div class="gmail_quote">Eu acho que os pacotes deveriam ter alguma inteligência para saber que estou utilizando local::lib ou perlbrew e instalar o módulos na estrutura local e não tentar instalar de maneira fixa na área de sistema.</div>

<div class="gmail_quote"><br>>Sugestões?</div><div class="gmail_quote"><br>
<div><div></div><div class="h5">=begin disclaimer<br>
   Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
 SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
 L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br>
</div></div></div><br><br clear="all"><br>-- <br>"o animal satisfeito dorme". - Guimarães Rosa<br>