[SP-pm] perlbrew

[Eden Cardim]

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

O caso 2.3 é igual o caso do .NET, onde o instalador te pede pra
instalar a versão X do runtime ou faz isso por você. Pro 2.2, Outra
solução é que, como as deps do perl são geralmente open source, nada te
impede de compilar e empacotar as bibliotecas dependentes junto.
Distribuições do namespace Alien:: costumam fazer isso num sharedir
justamente por esse motivo.

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

Mas isso, como eu ressaltei antes, é um problema de cultura e não de
restrição técnica, é que desenvolvedores java preferem re-escrever tudo
do zero invés de linkar com bibliotecas prontas, se você adotar a mesma
filosofia no perl, vai tudo funcionar perfeitamente igual no java, e
essas abordagens são possíveis a nível individual de projeto. Inclusive,
não é essa a principal motivação pela existência do mojolicious?    

    Alexei> Claro, na comunidade usamos muito Linux. No mercado, apesar de Linux
    Alexei> em servidores estar sempre crescendo, ainda se utiliza muitos sistemas
    Alexei> UNIX, principalmente em empresas grandes. Por UNIX, leia-se Solaris,
    Alexei> AIX, HPUX, etc... e pacotes nativos, pré-compilados, de Perl para
    Alexei> esses sistemas é algo bem difícil de se achar. O próprio interpretador
    Alexei> perl não é encontrado em suas últimas versões.

No caso, o que eu estou propondo é um sistema parecido com o cpantesters
ou macports, onde você pode submeter o resultado de um build num
repositório e sempre que alguém tentar compilar na mesma plataforma, ele
pega esse pacote pré-compilado invés disso. Existem builds pra todos
esses sistemas rodando em algum lugar por aí:
http://www.cpantesters.org/distro/M/Moose.html#Moose-2.0403. Não é tão
difícil prum *desenvolvedor* gerar esses pacotes e compilar perl na
maioria dos sistemas UNIX (até nos casos em que não se usa o toolchain
gnu). Eu faço isso com one-liners em sistemas Solaris com bastante
frequência e já fiz bastante no finado IRIX sem problema algum. Não vejo
porque nós como desenvolvedores não podemos tirar essa carga de cima dos
sysadmins pra eles pararem de reclamar que tem que rodar 3 comandos,
esperar 10 minutos, e quem sabe ajustar uma variável ou duas. E é
exatamente isso podia ser *bem* melhor no perlbrew, ele podia pegar um
pacote pré-compilado de algum lugar e só compilar se não houver um
pacote para aquela plataforma disponível, a compilação resultante vira
um pacote.

O problema maior aí eu acho que é outro, é que geralmente as empresas
que compram coisas como o Solaris/AIX/HPUX precisam de fontes
homologadas e contratadas para os binários que vão para produção, então
um esquema de compartilhamento de pacotes binários como eu to propondo
não seria viável nesses casos, mas só pela falta de homologação. (dai
vai um desenvolvedor java e enche o código de copy-paste da internet e
tá valendo, mas, vai entender, é assim que o mundo corporativo funciona)

    Alexei> Que é justamente o meu ponto: não existe algo como a versão binaria de
    Alexei> perl, pre-compilado para N plataformas. Se falarmos de uma biblioteca
    Alexei> "minima" para se trabalhar decentemente com Perl, nem se fale. Para
    Alexei> nós que somos "computeiros" instalação por compilação (e compilações
    Alexei> adjacentes) não é algo que assusta.

Existir existe, como mostra a tabela do cpan testers, o que não existe é
um mecanismo de hospedagem e distribuição desses binários.

    Alexei> Mas, para um gestor, isso traz preocupações:
    Alexei> - tempo gasto (compilar versus instalar um binário pronto)

Eu sinceramente não acho que seja esse o problema, compilar o perl leva
cerca de 10 minutos numa máquina caseira. Se fosse um gcc ou ghc, que
tem N fases de bootstrap, e realmente pode levar horas pra compilar, aí
sim, mas 10 minutos numa atividade que vai acontecer pouquíssimas vezes
não faz a menor diferença, na minha opinião.

    Alexei> - repetibilidade (em uma equipe de N pessoas realizando instalações,
    Alexei> podemos ter N compilações diferentes (em vários aspectos). Aí surge o
    Alexei> overhead de criar um procedimento padrão de compilação para a
    Alexei> ferramenta de programação (claro que o perlbrew ajudamuito nisso!).
    Alexei> Isso presumindo que os ambientes de trabalho das pessoas da equipe são
    Alexei> todos iguais - como geralmente, nas empresas, sempre há diferenças
    Alexei> entre as máquinas e/ou sistemas operacionais, aumenta-se o número de
    Alexei> variáveis para criar binários de Perl diferentes.

Um rsync do diretório do perlbrew resolve isso se as plataformas forem
compatíveis, novamente, já implantei diversas vezes assim em sistemas
Solaris. O que talvez ferraria aí é se houverem bibliotecas externas
incompatíveis entre os dois sistemas, mas isso pode ser resolvido
implantando a biblioteca dentro do diretório do perlbrew.

    Alexei> - rastreabilidade - em caso de m****, por exemplo um malware inserido
    Alexei> num pedaço de código, você não tem como comparar coisas básicas como
    Alexei> tamanho/data/digest de arquivos de uma máquina com o de outra (com
    Alexei> outra compilação), com a segurança de que vai

Sim, isso realmente é um problema, como eu mencionei antes, mas isso é
resolvido quando os binários compilados por desenvolvedores cotidianos
começarem a ser compartilhados.

    Alexei> - suporte (não-formal): como toda linguagem ou assunto, existe um
    Alexei> fórum (ou mais) na internet que o time de desenvolvimento irá
    Alexei> consultar para tirar dúvidas. No entanto, como não existe uma fonte
    Alexei> única de binários, o suporte fica potencialmente mais difícil, pois as
    Alexei> outras pessoas no(s) forum(ns) pode(m) ter compilado o perl/modulos de
    Alexei> inumeras maneiras diferentes, em inumeras variantes de ambientes.

Exatamente, e se houver um projeto de distribuição de binários
funcionando, ele acaba passando a ser o pivô desse suporte.

    Alexei> Chegamos exatamente ao mesmo ponto, por caminhos distintos. O que eu
    Alexei> falei ao Garu à época foi: "se eu tivesse muito tempo disponível e
    Alexei> nenhuma preocupação financeira", eu reservaria, tipo, um ano da minha
    Alexei> vida para criar um site onde se faz build e disponibiliza pacotes
    Alexei> binários de perl para N plataformas". Ou algo parecido ;-).
    Alexei> Infelizmente eu não tenho essa disponibilidade.

    Alexei> No entanto, eu ajudaria a direcionar/mentorizar/suportar/blablablar
    Alexei> algum voluntário a fazer isso. Por exemplo, no sourceforge tem (tinha,
    Alexei> pelo menos) um build farm com vários OSs diferentes, deve ser possível
    Alexei> utilizar essa estrutura para gerar os pacotes para sistemas mais
    Alexei> "esdrúxulos" (believe, compilar free software em AIX é uma aventura).

Você não precisa fazer o build, or builds já estão sendo feitos em
diversas máquinas mundo afora, você só precisa de um sistema que
empacote na máquina alvo e submeta pruma hospedagem. :) E o processo de
empacotamento não é tão complicado, é algo assim:

perl Makefile.PL
make
make test
tar -c blib

E talvez precise incluir o Makefile pra introspectar quais as libs foram
linkadas. Se houver um pedido específico de uma plataforma mais bizarra,
um voluntário qualquer pode montar a plataforma e usar o mecanismo de
submissão para enviar o pacote dele.

Sério, acho que dar o kickstart nisso é questão de *um* hackathon do
naipe do onde acontece, não de um ano. Só precisa consolidar e testar em
uma plataforma, as demais devem ter pouca diferença, isso se houver
alguma, e a gente conserta ao longo do caminho.

-- 
Eden Cardim
+55 11 9644 8225