There’s some confusion in the Rails community right now about two pieces of code with the same name: acts_as_taggable. Here are the differences as I understand them. Your corrections and clarifications are welcome!
For quite some time there has been a Ruby Gem called acts_as_taggable. You can learn more here: http://taggable.rubyforge.org. You install this by doing: ‘gem install acts_as_taggable’
In December 2005, the creator of Rails, David Heinemeier Hansson wrote a Rails plugin called acts_as_taggable. You install this by doing: ‘ruby script/plugin install acts_as_taggable’ You can see the genesis of the plugin during David’s presentation at the Snakes and Rubies event in Chicago. Audio and video, and pdf of David’s slides. Summary of differences:
The Gem
- The Gem has documentation.
- The Gem runs in Rails 1.0.
- The Gem has some community add-ons, such as Tom Fakes’ Tag Cloud.
The Plugin
- The Plugin doesn’t have much in the way of docs yet.
- The Plugin only works with Edge Rails, soon to be Rails 1.1. You can lock your app to Edge Rails by doing: ‘rake freeze_edge’ in your app directory. This will load a full copy of rails into your vendor directory, and Rails will by default look there and use that code if present.
- The Plugin was written using the new polymorphic associations, which is a cool approach.
- The Plugin is the one used in Chad Fowler’s new book, Rails Recipes. These are the best docs so far, even though the book is only beta.
- Generally, plugins are a better way to extend Rails.
In the long run, plugins are probably a better way to go, and the code for the plugin is clean. I myself prefer the approach of the plugin, but my skill level makes it hard to use without any docs.
I jumped on the Rails bandwagon a while ago, (see Avoiding Software Fear and ROR Bootcamp at BNR) so I don’t mean the following comments to be overly critical. But the situation is generating questions on the Rails list, and it’s just another opportunity for newbie confusion and ongoing list pollution. It’s easy to fix, too.
My thinking is that it’s unfortunate a leader in the Rails community chose to release this plugin without any docs, or without coordinating with the gem coders, or even announcing the differences to clarify the situation. But that’s the way it is. Eventually the plugin will have docs, the plugin and the gem may live together in peace, or one may become more popular than the other.
DHH said on the Rails mailing list: “Now here’s the truly wonderful part of open source: Creator, maintainer, and documentor needs not all be caps on the same schmoe. Thus, if you find something useful, say a plugin like acts_as_taggable with the creator stamp DHH, you can choose to express your gratitude through one of the other caps.
“That may be a patch to extend or it may be a tutorial about its usage or even READMEs and RDocs for the source. So try not to assume that creator equals sole maintainer or documentor. Only try to understand the truth: There is no vendor.”
It’s all true, but it’s worth considering this thought experiment: If someone else had released a plugin with the same name as a well-known gem, would the community have accepted it, or would they encourage the creator to change the name to avoid confusion? I assert that 1) the creator would have been encouraged to change the name, or take some other clarifying action, and 2) it is because DHH is the creator this didn’t happen. The magic of open source community still requires leadership, as well as management. In this example DHH shows his excellent management skills, and his growth opportunity in leadership.
I have been “expressing my gratitude” by clarifying the plugin and gem differences when questions come up on the mailing list, and by encouraging a more meta-solution, like writing docs, and trying to get the plugin working myself. If I do ever get it working, I’ll certainly post my code. (Note, it works fine for people who know what they’re doing – I’m just a newbie.) In the meantime, the Recipes book is the best introduction to the Plugin. And the gem works fine as well. Let a thousand flowers bloom.
Update – DHH responds on the Rail list:
Namespace clashes are problematic for packages that wants to be used concurrently, not for alternatives. How would the situation have improved if I had called it acts_as_polymorphically_taggable (except for making jokes about such a terrible, terrible name)? Would we not have had the same questions as to what does what and why? Of course we would.
In any case, let me summarize the difference quickly. The main difference is not plugin vs gem, but rather that my version of acts_as_taggable is designed to work with multiple classes. So a single tag can be used in the tagging of multiple classes. This requires polymorphic associations and join models, which is why it only works Edge Rails (and will work in the forthcoming 1.1).
So if you need that feature, tagging of multiple classes with the same tags, then use my version. Otherwise, the old version is probably better. It’s certainly more feature-rich and better documented.
Fair enough. Nice to have the clarification. For reference, the namespace clash I was referring to was the human-readable one, not whether Rails gets confused or not. (Though, acts_as_polytaggable wouldn’t have been so bad.) As a separate issue, yes, we would have had the same questions. The difference is they would have been answered up-front, rather than death-through-a-thousand-confused-list-messages approach we ended up with.
David’s a busy guy; obviously he shouldn’t have to do everything. Now that I have helped drive some clarification of the issue, how about if someone gets on the case of writing a good tutorial, and documenting the damn plugin!