[SP-pm] perlbrew

Fri Jun 22 14:33:45 PDT 2012

2012/6/22 Alexei Znamensky <russoz at gmail.com>

> Compare com um (perdoe-me senhor) Java Development Kit, que você faz
> download e copia para o servidor e *simplesmente executa*). Java pode ter
> seus N defeitos enquanto linguagem, mas do ponto de vista de um
> administrador de sistemas, é muito mais confortável que lidar com Perl.
>

Até pode ser, porém vc esta sujeito a problemas como classloader hell
(quando alguem colocou mais de um jar com a mesma classe em versões
diferentes e isso não é tão incomum assim) e a incompatibilitades com a JNI
(e ai descobre que quem fez não se preocupou com outro sistema
operacional). Mas seria otimo ter algo semelhante ao javaws para perl.

> pacotes pode ser feito da mesma forma como outras linguagens fazem. Por
>> exemplo, o debian distribui módulos perl pré-compilados a séculos, a Red
>> Hat também, e tem muitas shops que criam pacotes .deb ou .yum de suas
>> aplicações e dependências como mecanismo de deploy. O problema é que a
>> comunidade não menciona muito essas soluções porque a maioria das
>> pessoas que já estão dentro da comunidade não precisa delas, ou preferem
>>
>
> Claro, na comunidade usamos muito Linux. No mercado, apesar de Linux em
> servidores estar sempre crescendo, ainda se utiliza muitos sistemas UNIX,
> principalmente em empresas grandes. Por UNIX, leia-se Solaris, AIX, HPUX,
> etc... e pacotes nativos, pré-compilados, de Perl para esses sistemas é
> algo bem difícil de se achar. O próprio interpretador perl não é encontrado
> em suas últimas versões.
>
> Para Solaris, o site onde normalmente se acha os pacotes é o
>   http://www.sunfreeware.com
> lá, agora, a útlima versão de perl disponível é a 5.12.3, disponibilizada
> em 17/Fev/2011.
>
> Para AIX, o site "padrão" para ferramentas Linux-like é o
>
> http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html
> lá, agora, a última versão disponível é a 5.8.2 (quando eu saí da IBM em
> 2009, no papel de admin, eu me lembro de usar esse perl nos ambientes em
> que eu trabalhava)
>
>
>> compilar pra fugir da incompatibilidade binária. Eu particularmente
>> prefiro essa abordagem, (isso não quer dizer que é necessariamente a
>> "mais correta") e faço assim com todas as linguagens (inclusive as mais
>> mainstream). Isso não é um problema específico do perl, mas de toda
>> linguagem que fornece bindings pra bibliotecas escritas em outras
>> linguagens. A diferença pra maioria das outras linguagens é que
>> simplesmente não existe a cultura aqui de ter o trabalho de
>> disponibilizar pacotes pré-compilados em N plataformas.
>>
>
> Que é justamente o meu ponto: não existe algo como a versão binaria de
> perl, pre-compilado para N plataformas. Se falarmos de uma biblioteca
> "minima" para se trabalhar decentemente com Perl, nem se fale. Para nós que
> somos "computeiros" instalação por compilação (e compilações adjacentes)
> não é algo que assusta.
>
> Mas, para um gestor, isso traz preocupações:
> - tempo gasto (compilar versus instalar um binário pronto)
> - repetibilidade (em uma equipe de N pessoas realizando instalações,
> podemos ter N compilações diferentes (em vários aspectos). Aí surge o
> overhead de criar um procedimento padrão de compilação para a ferramenta de
> programação (claro que o perlbrew ajudamuito nisso!). Isso presumindo que
> os ambientes de trabalho das pessoas da equipe são todos iguais - como
> geralmente, nas empresas, sempre há diferenças entre as máquinas e/ou
> sistemas operacionais, aumenta-se o número de variáveis para criar binários
> de Perl diferentes.
> - rastreabilidade - em caso de m****, por exemplo um malware inserido num
> pedaço de código, você não tem como comparar coisas básicas como
> tamanho/data/digest de arquivos de uma máquina com o de outra (com outra
> compilação), com a segurança de que vai
> - suporte (não-formal): como toda linguagem ou assunto, existe um fórum
> (ou mais) na internet que o time de desenvolvimento irá consultar para
> tirar dúvidas. No entanto, como não existe uma fonte única de binários, o
> suporte fica potencialmente mais difícil, pois as outras pessoas no(s)
> forum(ns) pode(m) ter compilado o perl/modulos de inumeras maneiras
> diferentes, em inumeras variantes de ambientes.
>
>
>> Talvez o que esteja faltando é suporte dentro do cpan para a
>> distribuição desses pacotes. É uma questão de re-aproveitar compilações
>> executadas por usuários do cpan e submeter um bundle com o blib dentro
>> (é mais ou menos assim que funciona o sistema de testes hoje). Existem
>> sistemas que já funcionam assim, como o brew e o macports. Alguém topa
>> de criar e encarar o projeto? :)
>>
>
> Chegamos exatamente ao mesmo ponto, por caminhos distintos. O que eu falei
> ao Garu à época foi: "se eu tivesse muito tempo disponível e nenhuma
> preocupação financeira", eu reservaria, tipo, um ano da minha vida para
> criar um site onde se faz build e disponibiliza pacotes binários de perl
> para N plataformas". Ou algo parecido ;-). Infelizmente eu não tenho essa
> disponibilidade.
>
> No entanto, eu ajudaria a direcionar/mentorizar/suportar/blablablar algum
> voluntário a fazer isso. Por exemplo, no sourceforge tem (tinha, pelo
> menos) um build farm com vários OSs diferentes, deve ser possível utilizar
> essa estrutura para gerar os pacotes para sistemas mais "esdrúxulos"
> (believe, compilar free software em AIX é uma aventura).
>
> *** Ficou no draft durante o dia, e o Eden já complementou com alguns
> pensamentos. Mais tarde eu embalo na linha dele. Acho que temos uma idéia
> de desenvolvimento bem interessante aqui.
>
> Bom, to indo pegar meu vôo de volta pra casa. Fui!
>
> --
> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org
> GPG fingerprint = 42AB E78C B83A AE31 7D27  1CF3 C66F B5C7 71CA 9F3C
> http://www.flickr.com/photos/alexeiz | http://github.com/russoz
> "I don't know... fly casual!" -- Han Solo
>
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>

-- 
Tiago B. Peczenyj
Linux User #405772

http://pacman.blog.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20120622/cd327ea2/attachment.html>