What are the best practices to handle local gem modification

Ruby
1

hi there,

i hope i’m posting at the right place. i have the feeling that what i’m
asking is a very frequent issue, but somewhat i have not been ale to ask
it to google in the right way so i’m posting it here instead

basically, there’s this classifier gem that i want to use.
it depends on fast-stemmer
it works, i like it.

however, fast-stemmer may be fast, but it stems english words only. and
basically i am trying to stem french text. So it is not really stemming
it in the right way.

instead there’s this stemmer4r gem that actually supports french. The
gem is aging, but it’s source code is clean, the author seems to be
french and it support a large variety of european languages, so i
figured i could maybe modify the classifier gem so that it uses
stemmer4r instead of fast-stemmer.

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.

however, i know i am bound to face some issues in the near future if i
do nothing else:

  1. my hacked classifier gem resides in the gem directory, not in my
    working copy. so basically my modifications are NOT commited in my svn
    repository. it makes me feel very uncomfortable because if i checkout
    the repo on another machine, i will just have to make it all over again.
    a waste.

  2. i had to hack stemmer4r gem too because it wouldn’t install on cygwin
    (i had to modify a ruby file and a Makefile too ==>
    How to install the stemmer4r gem on Mac OS X and Linux
    those modifications are not commited in my svn repo either. (besides if
    they were, it would be easier to submit to patch to the author anyway)

  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

  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…
    Also, i know any rails app have a vendor directory that is somewhat
    dedicated to such things (put some third party libs there that you can
    later tweak or update if you want). but i am working on some pure ruby
    command line scripts for the moment, rails is off topic for now. besides
    i am not rails expert yet anyway.

i have the feeling that situation is probably classic for a lot of
people. So i do not want to reinvent the wheel here. instead, i would
rather apply best practices tested by other people and save the
trial&error process.

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

thanks

2

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 $:.

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

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