Rip is a new package management system for Ruby from the GitHub guys. It can handle various installation resources, like directories, files, Git repositories and RubyGems as well.
Another interesting new feature are Virtual Environments ("ripenvs"). Ripenvs can be used to install and manage multiple versions of a package, without getting conflicts. Ripenvs can also be handy to make upgrading of dependencies safer, just create a new experimental environment, upgrade there, and you can still go back to the stable environment if something breaks.
But why a completely new package manager? What's wrong with RubyGems? We asked one of Rip's developers, Chris Wanstrath:
There's no real problem with RubyGems. I love RubyGems. People seem to think that Rip was written to "fix" or supplant RubyGems. That's not it at all.
Rip was written to make installing, using, and managing packages awesome. It's written for the person installing the packages, not for the person distributing them. It's written for people who want to know exactly what versions of what libraries their application is using by typing a command, not by guesses and detective work. It's written for people who want to know about dependency conflicts when they're installing packages, when they're thinking about that stuff - not when they're launching their app, thinking about other stuff.
Rip was written for people who don't want to have to ask What version of X are you running? when trying to help you debug an issue. It's for people who want a guarantee that all their production machines are running the same libraries at the same versions. It's for people who want to test how upgrading a library will affect their environment before committing to the change.
Rip wasn't written by looking at what's wrong with other systems. It was written by looking at what's good with other systems.
Wouldn't it be easier to just adapt RubyGems?
Rip and RubyGems are very different beasts:So really, they're different projects with different goals. I do not believe it would have been easier (nor appropriate) to completely change the direction, core tenants, and underlying code of RubyGems. The two systems can live side by side and compliment each other nicely.
- Rip plays with your $LOAD_PATH while RubyGems overloads `require`.
- Rip works with $RUBYLIB while RubyGems necessitates a `require "rubygems"`.
- Rip manages multiple environments, each with a single version of each library, while RubyGems manages a single environment with different versions of each library.
- Rip can (theoretically) install any package type while RubyGems can install .gem files.
Virtual Environments also seem to be perfect for managing packages for different versions of Ruby, like JRuby.
Absolutely. This is the exact sort of thing Rip excels at – perhaps you'd like to publish different ripenvs (installable Rip Virtual Environments) for different Rubies. One for 1.9, one for 1.8, one for JRuby – with Rip it's easy for both you and the consumer.
That's just the way Rip works. No special features needed.
Rip has just been released in version 0.0.1, what have you planned for the future?
We haven't even begun to promote or even discover the power of ripenvs. Being able to share development environments with a single command (e.g. `rip freeze | gist`), merge development environments without fear of version conflicts, and the power to deploy your applications using ripenvs are just some of the ideas we'd like to focus on. They help show where Rip shines.
We'd also like to copy git's `reflog` idea so you can easily view or undo any changes you've made to any ripenv. You should never worry about losing data or your setup when using Rip.
We also have some great ideas to help you find packages when you know the name but not the URL.
And, naturally, support for hg, svn, and bzr is planned. You should be able to install from anywhere.
As far as Windows support goes, it's a must for Rip 1.0.
More on Rip as well as a short tutorial can be found on the Rip website.