27 Jan 2009

Why "require 'rubygems'" Is Wrong

The following screed was originally published at gist.github.com/54177 but has been copied here for posterity and because people keep asking me on IRC for the original link (it must be hard to find on gist for some reason).

tomayko.com   23:30

22 Apr 2010

Named Gem Environments and Bundler

Yehuda lays out some of the history and rationale behind Rubygems’s multi-package-version design and also takes a look at how a few recent tools (Bundler, Rip, rvm, etc.) are using different approaches to develop concepts around multiple “environments”.

I’ve never been a fan of Rubygems multi-versioned, directory-per-package approach to organizing packages. There’s a few different reasons, but mostly it forces a lot of unnecessary complexity into runtime that could (I think) be handled more simply at install time. I do like the convenience of installing a bunch of packages into a single Rubygems environment without having to think about it, but those benefits are outweighed by the subtle differences in runtime behavior, some of which can be extremely annoying (e.g., “already activated” errors). I’d rather be aware of and be forced to deal with those issues at install time. It’s great to see so much experimentation on new tools and alternative approaches.

yehudakatz.com   16:08

07 Mar 2010

gem-man(1) -- view a gem's man page

Perfect. This was a huge piece missing from Ron and I had no clue how to address it. Chris’s gem extension adds a gem man command that brings up the man page for any gem and works with any gem that includes normal roff man pages.

defunkt.github.com   03:35

26 Oct 2009

Gemcutter to replace Rubyforge

Gemcutter will become rubygems.org and Rubyforge will eventually go away entirely:

So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away. Migration paths for those projects will be provided, we’re not throwing any switches without warning. RubyGems.org will not be gaining any “bloat” from rewritten RubyForge features.

Wow. Congrats to @qrush and the Rubyforge team for pulling this off so quickly. Also, it’s pretty cool to see Heroku hosting a major/official piece of Ruby community infrastructure.

update.gemcutter.org   03:32

12 Jun 2009

Rip: A Next Generation Ruby Packaging System

There’s a nice combination of old and new concepts in here.

rubyinside.com   17:24