InfoQ

InfoQ

Notícias

Meus Favoritos

Faça oLogin ou Cadastre-se para ativar o recurso de favoritos por tempo ilimitado.

O conteúdo foi adicionado aos favoritos!

Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.

Rip: Um Novo Sistema de Gerenciamento de Pacotes para Ruby

Postado por Mirko Stocker , traduzido por Ricardo Yasuda em 25 Jun 2009

Seções
Desenvolvimento,
Operações e Infraestrutura
Tópicos
Package Managers ,
RubyGems ,
Ruby
Tags
git ,
github ,
RubyGems

Rip é um novo sistema de gerenciamento de pacotes para Ruby dos caras do GitHub. Ele pode lidar com vários recursos de instalação, como diretórios, arquivos, repositórios Git e também RubyGems.

Outra característica nova interessante são os Ambientes Virtuais ("ripenvs"). Ripenvs podem ser usados para instalar e gerenciar múltiplas versões de um pacote, sem ter conflitos. Ripenvs podem também ser úteis para tornar o upgrade de dependências mais seguro, apenas crie um novo ambiente experimental, atualize lá, e você pode ainda voltar para o ambiente estável se alguma coisa quebrar.

Mas por que um gerenciador de pacotes completamente novo? O que há de errado com RubyGems? Nós perguntamos a um dos desenvolvedores do Rip, Chris Wanstrath:

Não há um problema real com RubyGems. Eu amo RubyGems. Parece que as pessoas acham que o Rip foi escrito para "corrigir" ou suplantar RubyGems. Não é nada disso.

Rip foi escrito para tornar instalação, uso e gerenciamento de pacotes sensacional. Foi escrito para a pessoa que vai instalar os pacotes, não para a pessoa que vai distribui-los. Foi escrito para pessoas que querem saber exatamente quais versões de quais bibliotecas sua aplicação está usando com um comando, não adivinhando e com trabalho de detetive. Foi escrito para pessoas que querem saber sobre conflitos de dependênciias quando estão instalando pacotes, quando estão pensando sobre isso - não quando estão lançando a aplicação, pensando sobre outra coisa.

Rip foi escrito para pessoas que não querem ter que perguntar Que versão de X você está rodando? quando estão tentando ajudar você a debugar um problema. É para pessoas que querem a garantia de que todas as suas máquinas de produção estão rodando as mesmas bibliotecas nas mesmas versões. É para pessoas que querem testar como um upgrade de biblioteca vai afetar seu ambiente antes de fazer o commit da mudança.

Rip não foi escrito tendo base o que tem de errado com outros sistemas. Foi escrito tendo base o que é bom nos outros sistemas.

Não seria mais fácil apenas adaptar RubyGems?

Rip e RubyGems são coisas bem diferentes:
  • Rip brinca com seu $LOAD_PATH enquanto RubyGems sobrecarrega `require`.
  • Rip trabalha com $RUBYLIB enquanto RubyGems necessita um `require "rubygems"`.
  • Rip gerencia múltiplos ambientes, cada um com uma versão de cada biblioteca, enquanto RubyGems gerencia um ambiente único com diferentes versões de cada biblioteca.
  • Rip pode (teoricamente) instalar qualquer tipo de pacote enquanto RubyGems pode instalar arquivos.gem.
Então realmente são projetos diferentes com objetivos diferentes. Eu não acredito que seria mais fácil (nem apropriado) mudar completamente de direção, características principais e código do RubyGems. Os dois sistemas podem viver lado a lado e complementar um ao outro sem problemas.

Ambientes Virtuais também parecem ser perfeitos para gerenciar pacotes para diferentes versões do Ruby, como JRuby.

Com certeza. Este é o ponto onde Rip é melhor – talvez você gostaria de publicar diferentes ripenvs (Ambientes Virtuais Rip instaláveis) para diferentes Rubies. Um para 1.9, um para 1.8, um para JRuby – com Rip é fácil tanto para você quanto para o consumidor.

Rip funciona assim. Sem características especiais.

Rip acabou de ser lançado na versão 0.0.1, o que você planejou para o futuro?

Ainda não começamos a promover nem descobrir o poder dos ripenvs. Ser capaz de compartilhar ambientes de desenvolvimento com um simples comando (por exemplo `rip freeze | gist`), fazer um merge de ambientes de desenvolvimento sem medo de conflitos de versão, e o poder de fazer o deploy de suas aplicações usando ripenvs é apenas parte das ideias que gostaríamos de focar. Elas ajudam a mostrar onde Rip brilha.

Nós também gostaríamos de copiar a ideia do `reflog` do git para que você possa ver ou desfazer facilmente qualquer mudança que você tenha feito em qualquer ripenv. Você nunca deve se preocupar em perder dados ou seu setup quando estiver usando Rip.

Também temos ideias otimas para ajudá-lo a achar pacotes quando você sabe o nome mas não sabe a URL.

E, naturalmente, suporte para hg, svn, e bzr está nos planos. Você poderá instalar de qualquer lugar.

E quanto ao suporte ao Windows, é obrigatório para o Rip 1.0.

Mais sobre Rip e um pequeno tutorial pode ser encontrado no website do Rip.

Conteúdo Educacional

Formando equipes de alto desempenho, parte 1: Início e fases de evolução

Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.

Business Model Canvas, passo a passo

O Business Model Canvas é uma ferramenta estratégica para a construção visual de novos produtos ou serviços. Conheça cada um dos seus elementos e como preencher o Canvas, passo a passo.

Google Apps Script, Parte 2: Google Docs, triggers e envio de emails

Nessa segunda e última parte de uma série sobre o Google Apps Script, conheça como funciona o envio de emails, a conversão de documentos e como criar menus e triggers.

Serviços de cloud computing PaaS: um guia para desenvolvedores Java

Este artigo avalia seis dos mais importantes fornecedores de serviços de cloud computing PaaS para desenvolvedores Java, analisando critérios como desempenho, escalabilidade e tecnologias suportadas.

Canvas de Modelo de Negócios: uma contribuição para o sucesso de Startups

O Canvas de Modelo de Negócios é um novo modo de comunicar e suportar a validação iterativa, incremental e empírica de modelos de negócio de startups e novos produtos substituindo o plano de negócios.

Entrevista com Rebecca Parsons Parte 2: Agile Distribuído, Arquitetura vs. Design e SOA

Nesta segunda e última parte de uma entrevista exclusiva para InfoQ Brasil, Rebecca Parsons, CTO da ThoughtWorks, fala sobre o Agile Distribuído e técnicas para definição de arquiteturas.

Entrevista com Rebecca Parsons Parte 1: Agile nas Empresas e Arquitetura Evolucionária

Nessa primeira parte de uma entrevista com a CTO da ThoughtWorks, veja recomendações sobre formas de construir e arquitetar sistemas para obter o máximo de flexibilidade e responsividade a mudanças.

Agile das equipes à organização: o papel do gerente, estratégias e dicas para a adoção

Os gerentes de projetos podem assumir o papel crítico de liderar a introdução do Agile. Vejas conceitos, dicas e técnicas para apoiar esse processo de mudanças.