# Confusion about gems and non-gems working together **URL:** \ **Category:** ruby-talk\ **Created:** [17 June 2005 22:17 UTC](https://rubytalk.org/t/confusion-about-gems-and-non-gems-working-together/19048 "2005-06-17T22:17:52Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Lloyd\_Zusman](https://avatars.discourse-cdn.com/v4/letter/l/8baadc/32.png) [@Lloyd\_Zusman](https://rubytalk.org/u/Lloyd_Zusman)\ **Post date:** [17 June 2005 22:17 UTC](https://rubytalk.org/t/confusion-about-gems-and-non-gems-working-together/19048/1 "2005-06-17T22:17:52Z")
Ever since I started installing packages via the gems mechanism, I have kept running into problems that few others seemed to have (or at least mention here). More often than I would like, a gem installation would either fail outright, or else it would get installed but not work properly, yielding errors that seemed to be non-reproducible by others. I now think that I might have figured out what is going on for me: In all the cases where I had these problems, I had non-gem installs of earlier versions of the packages. In many cases, it seems like code inside of files associated with these earlier versions would get executed instead of the code that the newer gem would use. I have a standard ruby installation with no special path settings, and yet, I still am getting these unwanted interactions between certain gems and their older, non-gem counterparts. Has anyone else experienced anything like this? If so, how did you handle it? I presume that when I install a gem, I should completely uninstall any older, non-gem versions of the same package. What is the accepted way to uninstall a package? Do I just go into the ruby tree and delete all files and directories associated with the non-gem? If so, how can I find out what is the exhaustive list of files and directories to remove for a given package? This brings up a suggestion: could the gem installer check for previously installed non-gem versions of the package in question, and then ask the user if he/she wants to optionally delete them as part of the gem install? Something like that would be massively useful, IMHO. > **···** > > -- > Lloyd Zusman > [ljz@asfast.com](mailto:ljz@asfast.com) > God bless you. ---
**Author:** ![Chad\_Fowler4](https://avatars.discourse-cdn.com/v4/letter/c/9fc29f/32.png) [@Chad\_Fowler4](https://rubytalk.org/u/Chad_Fowler4)\ **Post date:** [18 June 2005 20:10 UTC](https://rubytalk.org/t/confusion-about-gems-and-non-gems-working-together/19048/2 "2005-06-18T20:10:54Z")
Hi Lloyd! > Ever since I started installing packages via the gems mechanism, I have > kept running into problems that few others seemed to have (or at least > mention here). More often than I would like, a gem installation would > either fail outright, or else it would get installed but not work > properly, yielding errors that seemed to be non-reproducible by others. > > I now think that I might have figured out what is going on for me: > > In all the cases where I had these problems, I had non-gem installs of > earlier versions of the packages. In many cases, it seems like code > inside of files associated with these earlier versions would get > executed instead of the code that the newer gem would use. > > I have a standard ruby installation with no special path settings, and > yet, I still am getting these unwanted interactions between certain gems > and their older, non-gem counterparts. > > Has anyone else experienced anything like this? If so, how did you > handle it? I haven't, but I don't use non-gem libs much anymore. Could you give a specific example? I think it might be instructive. As long as the gem version of the library is before the non-gem version in the load path (which it should be), you should get the gem version of the lib. Since that's obviously not the way it's working for you, it would be great to hear some specifics. > I presume that when I install a gem, I should completely uninstall any > older, non-gem versions of the same package. What is the accepted way > to uninstall a package? Do I just go into the ruby tree and delete all > files and directories associated with the non-gem? If so, how can I > find out what is the exhaustive list of files and directories to remove > for a given package? That's part of the problem pre-gems. There's no nice, repeatable way to do this. If you've got the original tar file lying around, you can look at it's contents and remove files that seem to have been installed by it. Even then, you'll probably want to use a checksum of some sort just in case installations of later libs over wrote files of the same name (which you might still be depending on). > This brings up a suggestion: could the gem installer check for > previously installed non-gem versions of the package in question, and > then ask the user if he/she wants to optionally delete them as part of > the gem install? Something like that would be massively useful, IMHO. I'll add it to our list. It would be hard to do cleanly and reliably, but as an optional user-verifiable setting, it wouldn't be too terribly evil. > **···** > > On 6/17/05, Lloyd Zusman \ wrote: > > > -- > > Lloyd Zusman > > ljz@asfast.com > > God bless you. > > -- > > Chad Fowler > [http://chadfowler.com](http://chadfowler.com) > > > **[Ruby Central](https://rubycentral.org)** > > > > Supporting the Ruby Community Since 2001 > > > **[WebMD - Better information. Better health.](https://www.rubygarden.org/)** > > > > The leading source for trustworthy and timely health and medical news and information. Providing credible health information, supportive community, and educational services by blending award-winning expertise in content, community services, expert... > > [http://rubygems.rubyforge.org](http://rubygems.rubyforge.org) (over 300,000 gems served!) ---
**Author:** ![Jim\_Weirich1](https://avatars.discourse-cdn.com/v4/letter/j/73ab20/32.png) [@Jim\_Weirich1](https://rubytalk.org/u/Jim_Weirich1)\ **Post date:** [19 June 2005 02:08 UTC](https://rubytalk.org/t/confusion-about-gems-and-non-gems-working-together/19048/3 "2005-06-19T02:08:52Z")
If no explicit require\_gem is done on the library, then the non-gem version will take precedence. If there is no non-gem version, or an explicit require\_gem has requested the library, then the gem version will be used. > **···** > > On Saturday 18 June 2005 04:10 pm, Chad Fowler wrote: > > > \> In all the cases where I had these problems, I had non-gem installs of > > \> earlier versions of the packages. In many cases, it seems like code > > \> inside of files associated with these earlier versions would get > > \> executed instead of the code that the newer gem would use. > > \> [...] > > \> Has anyone else experienced anything like this? If so, how did you > > \> handle it? > > > > I haven't, but I don't use non-gem libs much anymore. [...] > > As long as the gem version of the library > > is before the non-gem version in the load path (which it should be), you > > should get the gem version of the lib. > > -- > -- Jim Weirich jim@weirichhouse.org [http://onestepback.org](http://onestepback.org) > ----------------------------------------------------------------- > "Beware of bugs in the above code; I have only proved it correct, > not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) ---
**Author:** ![Lloyd\_Zusman](https://avatars.discourse-cdn.com/v4/letter/l/8baadc/32.png) [@Lloyd\_Zusman](https://rubytalk.org/u/Lloyd_Zusman)\ **Post date:** [20 June 2005 23:23 UTC](https://rubytalk.org/t/confusion-about-gems-and-non-gems-working-together/19048/4 "2005-06-20T23:23:06Z")
Chad Fowler \ writes: > Hi Lloyd! Hi Chad! 🙂 > [...] > > > I now think that I might have figured out what is going on for me: > > > > In all the cases where I had these problems, I had non-gem installs of > > earlier versions of the packages. In many cases, it seems like code > > inside of files associated with these earlier versions would get > > executed instead of the code that the newer gem would use. > > > > [...] > > > > Has anyone else experienced anything like this? If so, how did you > > handle it? > > I haven't, but I don't use non-gem libs much anymore. Could you give > a specific example? I think it might be instructive. As long as the > gem version of the library is before the non-gem version in the load > path (which it should be), you should get the gem version of the lib. > Since that's obviously not the way it's working for you, it would be > great to hear some specifics. Well, prior to receiving this message of yours, I had fixed all occurrences of this problem by manually deleting the non-gem versions of the offending packages. Therefore, it's hard to reproduce now. However, one case I recall clearly where I had consistent problems was when I first installed the gem version of wee. I had installed an earlier non-gem version, and until I deleted that, I couldn't even get the gem install to work. My messages about this problem should be in the archives of this mailing list, although that was before I thought of the possibility that the non-gem version might be interfering with the gem. > > [...] If so, how can I find out what is the exhaustive list of > > files and directories to remove for a given package? > > That's part of the problem pre-gems. There's no nice, repeatable way > to do this. If you've got the original tar file lying around, you can > look at it's contents and remove files that seem to have been > installed by it. [...] Yes, that's what I have done during the manual uninstalls that I mentioned above. > [...] Even then, you'll probably want to use a checksum of some > sort just in case installations of later libs over wrote files of the > same name (which you might still be depending on). I didn't do that in this case. I hope I don't get bit. > > This brings up a suggestion: could the gem installer check for > > previously installed non-gem versions of the package in question, and > > then ask the user if he/she wants to optionally delete them as part of > > the gem install? [...] > > I'll add it to our list. It would be hard to do cleanly and reliably, > but as an optional user-verifiable setting, it wouldn't be too > terribly evil. As I mentioned earlier, I would find it amply useful, and I'm sure that I'm not the only person. > **···** > > -- > Lloyd Zusman > ljz@asfast.com > God bless you.