views:

61

answers:

4

I have some logic code that is literally cut and pasted across several different sites I own (it's code that interacts with a web API I've created). Considering that this isn't DRY and that when I update one thing I want it to update across all my sites I wanted to move this to a gem or a plugin. My main question is which one is the best to use in this scenario?

One big sticking point is that this code is private and shouldn't be made available to just anyone.

Thanks

A: 

Let's see Pros / Cons:

Gems

Pros

  1. Easier to update the version (gem update)
  2. Code encapsulated and available for all applications on the machine

    Cons

  3. Webapp code and gem code aren't encapsulated together.

  4. You have to install every gem on each pc the application will run.
  5. You have to install rubygems on each pc, too.
  6. Maybe it's nedeed to be sudoer to install the gem.

Plugins

Pros

  1. Code encapsulated within the application
  2. You don't need special rights on the machine to work.
  3. You don't need rubygems.

    Cons

  4. More difficult to update the code than gems

  5. You have to install the plugin on every application that will need it.

I think this are all the differences. The decission now is yours :)

For me both solutions are OK, you have to think about your needs.

Hope that helps.

pablorc
You can unpack the gems and build them (if needed) to pack it with your application, so that won't really be a problem ;-). rake gems:unpack / rake gems:build
Hock
A: 

Gems are the de-facto standard for packaging and releasing Ruby libraries.

There used to be two major drawbacks to using gems instead of plugins in Rails applications. Gems did not have access to all the functionality that plugins had. For example, in Rails 2, gems could not directly add rake tasks to your application. In Rails 3, plugins and gems are completely equal.

The second drawback was that gems were harder to bundle with your application. This has been resolved a while ago by rake gems:unpack:dependencies. It copies all gems your application depends on to your app's vendor/gems application. If you deploy these with your application, there is no need to install them on remote servers. In Rails 3, the new gem bundler further improves this mechanism. It even allows you to bundle Ruby C-extensions!

Also consider the things that cannot be done with plugins: versioning, packaging, dependency management, extending Ruby, etc.

In my opinion there is no serious reason to use plugins instead of gems anymore. The last advantage of plugins will be void when Rails 3 is released. Spread the word, and help everyone convert their plugins to gems!

molf
A: 

Will you ever have more than one version of this API being used in production at the same time?

If not, the simplicity and flexibility of a plugin is probably easier, especially if you use a tool like Piston to install/update the plugin from a centralized code repository.

Winfield
A: 

Gems are not too convenient for private stuff, imo, with the way they're distributed. And distributing them by hand avoiding the gem hosts is an overhead. If it was me and I had a piece of private code I need to use in a bunch of places, I'd simply throw it into lib/ dir as a fake git submodule. Then pull once in a while.

hakunin