Confusion about gems and non-gems working together.

[Lloyd Zusman]

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.

 

[Chad Fowler]

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.
=20
I now think that I might have figured out what is going on for me:
=20
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.
=20
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.
=20
Has anyone else experienced anything like this? If so, how did you
handle it?
=20

I haven't, but I don't use non-gem libs much anymore. Could you give a spe=
cific
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 sh=
ould
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?
=20

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.
=20

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.

=20
--
Lloyd Zusman
(e-mail address removed)
God bless you.
=20
=20
=20

--=20

Chad Fowler
http://chadfowler.com
http://rubycentral.org=20
http://rubygarden.org=20
http://rubygems.rubyforge.org (over 300,000 gems served!)

 

[Jim Weirich]

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.

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.

 

[Lloyd Zusman]

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.