There have been questions with answers on how to write rubygems, but what should you avoid in writing a rubygem? What can cause problems for people using your rubygem?
1 Answers
Gem Packaging: Best Practices gives a lot of advice, some of which include
Don't pollute the global load path. Ideally, only have
foo.rb
in yourlib
directory, and put all your other files inlib/foo
.Don't
require
files using__FILE__
.Don't rely on anything outside the load path. Folders may not have the same structure as in your original version. For example, don't use something like
VERSION = ::File.read(::File.join(::File.dirname(FILE), "..", "..", "VERSION")).strip
Don't manage
$LOAD_PATH
withinlib
.Provide a
VERSION
constant.Don't depend on rubygems. The person using your code may not be using rubygems, but some other packaging system (or no packaging system). Similarly, don't mention version dependencies in the code itself, or
rescue Gem::LoadError
.
Rubygems dependencies. Please... argues that you shouldn't list optional runtime dependencies, and should separate developer from runtime dependencies.
From my own experience: if nothing else, try building and installing your gem locally before releasing it into the wild. It avoids brown paper bag releases.

- 78,473
- 57
- 200
- 338
-
Definitely a good and correct writeup, especially with the reference to "Gem Packaging: Best Practices" – Dominik Honnef Apr 11 '10 at 06:58
-
Your last point is very important. It could basically be rephrased as: "One important gotcha for writing Ruby Gems is not to write Gems, write libraries." – Jörg W Mittag Apr 11 '10 at 08:38
-
@Jörg: Very Zen-like. (The last point from "Gem Packaging: Best Practices" that is, not the "From my own experience") – Andrew Grimm Apr 12 '10 at 23:29