From: David Masover <ninja@...>
Date: 2010-09-05T04:23:56+09:00
Subject: Re: what are the best practices to handle local gem modification

On Saturday, September 04, 2010 10:59:23 am Fourchette Fourchette wrote:
> after one hour or so, i got it up and running. My new hacked version of
> the classifier gem uses stemmer4r and works nicely with french text.

Find the author of the classifier gem, or better yet, find a Github repo or 
something, and send a patch.

> 1. my hacked classifier gem resides in the gem directory, not in my
> working copy.

You can always put a copy of the gem in some 'lib' directory of your working 
copy, and prepend that to $:.

> 3. what happens if classifier gem gets updated and i make a gem update?
> i guess either the classifier gem won't be updated or my hacked version
> of the gem will break, or both. besides, i may want to integrate such
> modification in my own version of classifier

The new version would be installed in a new directory. You can force a 
specific version with Kernel#gem, but that doesn't help you integrate those 
changes.

But this is exactly what version control is for. In the future, do NOT make 
changes to an installed gem. Instead, find the source repository for that gem, 
make your changes to a local branch, and build from that branch to install a 
gem -- or add that branch to your project's path temporarily, for testing. 
That way, when you're done, you can send a patch back to the gem, or you can 
fork the project and maintain your own version.

> 4. i know svn has the concept of a vendor branch, i read this in the svn
> red book a few years ago but never really encountered a situation where
> i would have to tweak a third party lib before so i'm not really used to
> this feature...

Most Ruby people aren't using SVN. They're using Git, and you should be, too. 
Git does have a concept of a submodule, but this probably isn't what you want, 
since it's not that you want to track a specific revision of upstream -- and 
if you did, Gem would be enough. Rather, it's that you want to fork it.

Now, Rails has a concept of a vendor branch, where you can simply unpack a gem 
to a "vendor" folder under your project, but I'm pretty sure this doesn't use 
any scm features, and you're responsible for keeping it in sync. Seems pretty 
inconvenient compared to using the native features of something like Git to 
handle tracking new changes.

> what are the best practices to handle local gem modifications in this
> with-svn / without-rails context?

Best practices are:

 1: Use Git, not SVN.
 2: Don't modify the installed gem. Instead, go find its source repository and 
work from there.