what are the best practices to handle local gem modification

[Fourchette Fourchette]

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 ==>
http://snippets.aktagon.com/snippets/165-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

 

[David Masover]

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.