---------- Mensagem encaminhada ---------- >De: Tiago Peczenyj <[email protected]> >Data: 15 de junho de 2011 11:27 >Assunto: Re: [SP-pm] Teen sells Perl cloud startup to ActiveState >Para: [email protected] > > >Aproveitando para mudar um pouco de assunto mas dentro do tema. > >Qual seria a melhor forma de fazer deploy do Catalyst (ou Dancer, ou >Mojo) em produção? Eu poderia instalar via .deb ou .rpm OU preciso >instalar todos os pacotes "na mão"? Dentro das dependências do >Catalyst tem algo que existe build essencials (gcc)?
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. >Pergunto pq eu trabalho fazendo deploy em maquinas CentOS e sempre >tenho que fazer RPMs para fazer deploy de aplicações em Perl mas todos >eram scripts standalone ou serviços rodados via crontab. 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. >Atualmente estamos usando para web Python, Ruby e Java e em cada um a >gerência de pacotes é estressante: no caso do Python podemos utilizar >o pip mas recentemente tivemos uma divergencia com a versão de libcurl >que consumiu 2 dias inteiros. Com rubygems ocorre a mesma coisa e Java >ficou abandonado (com todos os jars no mesmo diretorio... adivinhem o >que acontece? ClassLoaderHell! mas isso é erro de projeto...). > Recentemente a Mac fez uma coisa que 'congelou' e dificultou muito a instalação de módulos via cpan. Na london.pm 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. >Não vejo como o CPAN poderia resolver o meu problema e estou inclinado >a gerar RPMs (preferia gerar .deb mas fazer o que...). Sinto que estou >olhado o problema pela perspectiva errada, mas começo a concordar que >servidor de produção não deve ter gcc ou build-essencials e utilizar >multiplos gerenciadores de pacotes num ambiente sem a disciplina de >gerência de configuração (pelo menos começamos a usaro Puppet! um >passo de cada vez...) é complicado para dizer o mínimo. > 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. >Sugestões? =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer -- "o animal satisfeito dorme". - Guimarães Rosa
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
