Rip: A Next Generation Ruby Packaging System – Watch Out RubyGems!
Earlier this week, Rip quietly made its way into the world. It's a "next generation" Ruby packaging system, clearly meant to both work around some of the problems with RubyGems and also introduce some fresh ideas of its own. If you want to immediately jump and learn more, check out the official About us page for a tour.
Rip comes from the Github and Sinatra stables with the primary contributors being Chris Wanstrath, Jeff Hodges, Tom Preston-Werner, John Barnette, Blake Mizerany, Ryan Tomayko and Pat Nakajima. This is no "crazy renegade" project, although the developers are keen to stress the existing version is only a "development alpha" to be tested and built upon - not used in production.
Rip has a number of compelling features that make it worth considering for the future. Firstly, it provides another level of abstraction above existing RubyGems, Git repositories, and file structures, in the form of packages. It also supports the creation of virtual environments that can exist simultaneously but wherein different sets of libraries can be installed. Taking a cue from Git, Rip is also decentralized. There's no canonical server for Rip packages - they'll be retrieved from wherever the library developer specifies. This means you won't be able to do anything quite as simple as gem install library, but we're already used to using URLs for other forms of content, so why not library files?
Basically, Rip's a new tool with a whole new way of looking at Ruby packaging and library distribution, but it has a killer team behind it, some solid ideas, and it could well supersede RubyGems in many ways in the near future. We've had rapid tool switches before in the Ruby world (think how quickly Git became entrenched) so I wouldn't be surprised if Rip becomes a big deal over the next several months..
Also worth seeing.. Beginning iPhone Programming Workshop For Rubyists. A companion class to the FutureRuby conference. Toronto, July 9-10, 
June 13, 2009 at 2:39 am
I read over the About page. I'm afraid I don't see anything compelling there.
"Rip's support for a variety of package types means there is nothing to build and distribute."
How's that going to work? I don't want precompiled Windows binaries mixed in as part of my checked-in code. Or am I missing something here? And does rip work on Windows?
"Tag your Git repository and publicize the latest version, or just pass around Gists. Rip does not care."
So, it's designed around git...
"Rip makes it easy to have multiple environments with different versions of libraries."
You can already have multiple versions of libraries with rubygems and require the ones you need if you want to lock into a specific version or branch. What's compelling about this?
"Rip requires no changes to your code, only an optional deps.rip file added to the root of your project. As a result you do not force Rip on anyone else and individuals are free to re-package your code using other systems."
But only as long as they use git, right? Rubygems does not compel you to use any particular SCM.
"There is no canonical server for Rip packages, which may be good or bad."
Bad if we'll have to specify URL's explicitly. Oh, I'm sure that's fine for the Rails power users who know exactly where to look for every library they want. Everyone else? Too high a barrier to entry. Joe Schmoe system administrator or newbie programmer doesn't have a clue.
What am I missing?
June 13, 2009 at 4:23 am
You know, I'm usually pretty pleased with stuff that that gang puts out. I don't really care for RubyGems, it's got some serious design flaws, but I don't see how Rip is a significant improvement. It does some stuff better, but I just don't see how any package manager can take over from RubyGems without just absolutely hitting one out of the park. And at least from my perspective, Rip hasn't even come close to doing that.
That said, with some minor changes in direction perhaps, yeah, this could really be a big improvement. I really dig the decentralization. Github demonstrated the value of drop-dead-easy forking, and Rip embraces that future. I like that. I really like that Rip has the good sense not to monkey-patch require. I hate the fact that Rip touched my .profile file without first asking politely or giving me the opportunity to opt out or handle it manually myself. Especially because, for my environment anyways, it got the variables wrong. I'm extremely worried about all packages in an environment sharing the same directory. That seems like it'll inevitably lead to conflicts and namespace issues. It's great that each package gets it's own completely separate directory in rip-packages, but merging everything together within the environment directory relies on too many assumptions for my tastes. I don't really like the "active" symlink either. It strikes me as a deployment distopia waiting to happen.
Daniel is wrong though about specifying URI's manually. URI's are the preeminent tool in the decentralization toolbox. They're easy to explain in a tutorial, and they do the job better than anything else. Right now, the only advantage short gem names have over URIs is that there's fewer characters to type. People don't guess gem names. People don't know where to look for every library they want, not even power users. We have Google for that. There's nothing stopping any of us from picking up a URI off of a README found via Google. We already do it for Rails plugins in fact.
June 13, 2009 at 8:33 am
Ugh.. all these choices: SVN/Git, Test::Unit/RSpec/Shoulda, ERb/Haml, Passenger/Mongrel/Glassfish/FastCGI and now RubyGems/RIP. Why do we keep making this stuff so complicated? This can really put new Ruby/Rails developers off.
June 13, 2009 at 9:35 am
@Martijn, Are you new? Welcome to software development world.
June 13, 2009 at 12:54 pm
A rubygems plugin might be a kinder way...dunno
-=r
June 14, 2009 at 2:37 am
@roger, I agree. Rubygems plugin.
June 14, 2009 at 5:40 am
Hi Bob,
The active symlink is a convenience for the shell user. When running Ruby processes and daemons you'll want to specify the ripenv explicitly.
This is how you achieve multiple daemons running different versions of the same library in a conflict free manner.
Cheers,
Chris
June 14, 2009 at 5:42 am
Hi Daniel,
Rip does not require Git and is not designed around Git.
Cheers,
Chris
June 14, 2009 at 5:59 am
Hi Martijn,
Rip is backwards compatible with RubyGems. You can continue to use both, just one, or neither.
They complement one another nicely and should not be seen as mutually exclusive.
Cheers,
Chris
June 14, 2009 at 4:50 pm
i'd like to see this evolved to not utilize gems that require native extensions so that it's alternative implementation friendly, until then, i'm better off not becoming entangled with it ...
June 15, 2009 at 4:32 am
I hate being confused about new shiny tools, but I am.
June 16, 2009 at 10:37 am
change is cool; but still, rubygems is kind of a core tool…
more powerful rubygems, more reliable ?
nope, here's some new stuff…
@doc : I get lost too.
June 19, 2009 at 2:24 pm
a GEM replacement will never be of any use to me if it's not able to go through that NTLM Microsoft proxy horror (that is, forcing me to spend hours in hacking a proxy here and there to be able ton install gems on my company's PC (which is forbidden, but heck, Ruby's so great I can't miss it))
June 19, 2009 at 3:13 pm
I am really surprised that no one mentioned Python virtualenv since afterall that seems to be a fairly strong inspiration for rip—that is, a tool for creating isolated environments. To supplement this discussion you should read Yehuda Katz's recent blog post on Rubygems issues and potential solutions: http://yehudakatz.com/2009/06/15/rubygems-problems-and-proposed-solutions/