views:

73

answers:

1

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?

+3  A: 

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 your lib directory, and put all your other files in lib/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 within lib.

  • 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.

Andrew Grimm
Definitely a good and correct writeup, especially with the reference to "Gem Packaging: Best Practices"
dominikh
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
@Jörg: Very Zen-like. (The last point from "Gem Packaging: Best Practices" that is, not the "From my own experience")
Andrew Grimm