[SP-pm] perlbrew

Alexei Znamensky russoz at gmail.com
Fri Jun 22 14:24:06 PDT 2012


2012/6/21 Eden Cardim <edencardim em gmail.com>
[...]

> Olha, sem querer chato mas, existem sim soluções para distribuição de
> pacotes pré-compilados e o processo de criação e distribuição desses
>

Claro que existem. Como eu escrevi, nenhuma delas é (IMHO) atraente para o
mercado em larga escala. Usa-se XS, principalmente, por dois motivos:

1) performance
2) linkar com biblioteca nativa

No caso 1), é menos mal porque não há dependências externas (ao Perl),
então pode-se facilmente levar um módulo XS compilado de um sistema Linux
para outro (claro, podem existir complicadores, estou ignorando-os para
este argumento).

No caso 2), você não pode somente levar o seu módulo XS compilado. Você
precisa lidar com a(s) biblioteca(s) externa. Você pode:
2.1) compilá-la
2.2) levá-la compilada junto (não sei se alguma ferramenta permite isso)
2.3) exigir que o usuário/administrador da máquina instale

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.

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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20120622/ae31aa4a/attachment-0001.html>


More information about the SaoPaulo-pm mailing list